[twitter-dev] Feedback wanted on Twitter + iOS
Hey all, With iOS 5 and the Twitter integration coming in a few months, we have been getting a ton of inbound interest and questions around how to effectively leverage the Twitter integration. We wanted to get your feedback on how we can best support you and your users in developing meaningful experiences. I also hope you have had a chance to dig into the documentationhttps://developer.apple.com/library/prerelease/ios/#documentation/Twitter/Reference/TwitterFrameworkReference/_index.html%23//apple_ref/doc/uid/TP40011014and watch the WWDC session videohttps://deimos.apple.com/WebObjects/Core.woa/BrowsePrivately/adc.apple.com.8270634034.08270634040.8367260933?i=1372307634 . We've heard that it would be helpful for us to provide some standard graphics for use with your upcoming iOS integrations. We wanted to understand what types of buttons and styles would be most helpful. We think the most common use case is going to be Sign in with Twitter (SSO) but let us know what formats would be helpful. The two use cases that we're hearing the most interest around are: 1. Instant personalization - frictionless Single Sign-on (SSO) and social graph will allow apps to provide a personalized experience to their users with one click. What things can we provide to make this more effective for you. 2. Distribution - using the build-in Tweet Sheet functionality to post great content from your app out to the Twitter stream where it will drive engagement and clicks back to your application. Let us know if there are any other resources that would help make your Twitter iOS integrations easier on you or help you provide more value to your users on iOS. We'd love to see your apps, give feedback and help make developing on Twitter and iOS 5 a great experience so let us know how we can help. Ryan -- Ryan Sarver @rsarver https://twitter.com/intent/follow?screen_name=rsarver -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Feedback wanted on Twitter + iOS
Paul, thanks for following up and we definitely understand where you are coming from. The current Apple implementation allows for a single permission for all apps and therefore we have to err on the side of being less permissive. The vast majority of the apps will not need DM read access and we need to optimize for that. We definitely understand the needs and we're exploring options on our side to make it happen. stay tuned -- Ryan Sarver @rsarver https://twitter.com/intent/follow?screen_name=rsarver On Tue, Jun 28, 2011 at 4:48 PM, Paul Haddad paul.had...@gmail.com wrote: Ryan, On Jun 28, 2011, at 6:44 PM, Ryan Sarver wrote: We'd love to see your apps, give feedback and help make developing on Twitter and iOS 5 a great experience so let us know how we can help. Simple, open up access to DMs via the API. --- Paul Haddad paul.had...@gmail.com, p...@tapbots.com, p...@pth.com -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Feedback wanted on Twitter + iOS
Tom, by the time this launches all apps using TWRequest will get proper attribution like from YourApp on iOS :) -- Ryan Sarver @rsarver https://twitter.com/intent/follow?screen_name=rsarver On Tue, Jun 28, 2011 at 5:07 PM, Tom van der Woerdt i...@tvdw.eu wrote: First of all, I think Twitter should make it more clear that this implementation is focused on providing Twitter access for non-client apps. Think of this implementation as a 'post on Twitter' feature that doesn't require any API knowledge or other very complicated stuff. That, and you have the ability to get some information about the user. I think it would be a very bad thing if this gave the app DM level access as that kind of access is either abused or for client apps and this framework isn't for either of those. What I noticed while studying the framework (and I'll avoid violating the Apple NDA here) is that the requests are signed using a fixed pair of credentials and always say 'from iOS'. It would be very nice to be able to make that say something like 'from appname on iOS' or something. I think that a LOT of devs are going to ask for that. I have some other ideas but they are improvements over the current framework and if I posted them on a public list I'd have to shoot you ;-) Tom On Jun 29, 2011, at 1:44 AM, Ryan Sarver rsar...@twitter.com wrote: Hey all, With iOS 5 and the Twitter integration coming in a few months, we have been getting a ton of inbound interest and questions around how to effectively leverage the Twitter integration. We wanted to get your feedback on how we can best support you and your users in developing meaningful experiences. I also hope you have had a chance to dig into the documentationhttps://developer.apple.com/library/prerelease/ios/#documentation/Twitter/Reference/TwitterFrameworkReference/_index.html%23//apple_ref/doc/uid/TP40011014and watch the WWDC session videohttps://deimos.apple.com/WebObjects/Core.woa/BrowsePrivately/adc.apple.com.8270634034.08270634040.8367260933?i=1372307634 . We've heard that it would be helpful for us to provide some standard graphics for use with your upcoming iOS integrations. We wanted to understand what types of buttons and styles would be most helpful. We think the most common use case is going to be Sign in with Twitter (SSO) but let us know what formats would be helpful. The two use cases that we're hearing the most interest around are: 1. Instant personalization - frictionless Single Sign-on (SSO) and social graph will allow apps to provide a personalized experience to their users with one click. What things can we provide to make this more effective for you. 2. Distribution - using the build-in Tweet Sheet functionality to post great content from your app out to the Twitter stream where it will drive engagement and clicks back to your application. Let us know if there are any other resources that would help make your Twitter iOS integrations easier on you or help you provide more value to your users on iOS. We'd love to see your apps, give feedback and help make developing on Twitter and iOS 5 a great experience so let us know how we can help. Ryan -- Ryan Sarver @rsarver https://twitter.com/intent/follow?screen_name=rsarver -- Twitter developer documentation and resources: https://dev.twitter.com/dochttps://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: consistency and ecosystem opportunities
Steve, thanks for the email. Some inline responses below... -- Ryan Sarver @rsarver http://twitter.com/rsarver On Wed, Mar 16, 2011 at 8:24 PM, Steve Eley sfe...@gmail.com wrote: On Mar 11, 4:18 pm, Ryan Sarver rsar...@twitter.com wrote: With more people joining Twitter and accessing the service in multiple ways, a consistent user experience is more crucial than ever. As we talked about last April, this was our motivation for buying Tweetie and developing our own official iPhone app. It is the reason why we have developed official apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on their Twitter for Blackberry app. As a result, the top five ways that people access Twitter are official Twitter apps. Something doesn't sound right here. The official reasoning has some contradictions in it: * You're telling us that Twitter's own apps are topping the market, and that an overwhelming majority of people are engaging with Twitter using your own tools. 90% logging in once a month is one measurement. We can't currently measure tweet views which would be the best measurement of consumption. I wouldn't say that Twitter is the overwhelming majority of the way people consume twitter, but it's the majority and trending in that favor. * In the same message, you say that people are confused about how to engage with Twitter. You blame non-standard third party interfaces -- but if they're just a small minority of user contact points with Twitter, wouldn't the impact be fairly low-level and mitigated by the superior first-party experience? While Twitter owned and operated clients are the majority, but not the overwhelming majority, there is still a lot of confusion for mainstream users across the fractured experiences. * In that message and in subsequent followups, you tell us that client applications will be held to a higher bar. This seems to imply that the standards for acceptance or rejection are qualitative; however, the revised Terms of Service imply that they are objective. Which is it? Is it If you implement X, we'll cut you off -- or is it We encourage you not to implement X, but if you do, we'll decide whether you're any good at it? Clearly people have taken this to mean something I didn't intend. When I said higher bar I meant that relative to the previous TOS. I don't mean it in an arbitrary, qualitative way. While we don't recommend it as a business, we aren't going to be turning off clients as long as they stay within the articulated TOS. Obviously there are a number of smaller international markets, use cases and devices that our clients don't address and these are great for niche clients. Fundamentally, here's what doesn't smell right to me: if the superior quality of Twitter's first-party platform is winning in the marketplace, as you say it is, _why bother with this?_ The perceived threat to the user experience doesn't make sense. New users who don't understand Twitter yet aren't going to pick up third-party clients; they're going to follow the brand name. They'll go to Twitter.com, or buy a book, or ask their friends. (If the books or friends are confused, new API terms won't help.) Why bother? Because on a weekly, if not daily basis, we get asked by developers, entrepreneurs, angels and VCs for more guidance and transparency. If we know we are going to invest heavily in a space and feel that a consistent user experience is key to onboarding more new users and optimizing the network effects, then we need to communicate that to everyone. The email was meant to be blunt, and we know it's not a message that everyone wants to hear. Some people have taken acception to the bluntness of the language, but I think brutal honesty is better than dancing around the topic with niceties. GOOD third-party clients don't compete with Twitter for new user share. They pick up the power users who've used Twitter for a while and want to use it more, or who have particular needs or tastes, or who _like_ crazy non-standard designs. Shutting them down won't help new users, and it won't enable current users to do things better. It'll just turn power users into non-power users, or in some cases into non-users. The most valuable users don't settle for 'good enough.' If Twitter doesn't let them do things their own way, they'll find a platform that does, or make one. I totally agree, hence why I called out applications focused on the enterprise market and marketers like HootSuite, CoTweet and Seesmic. And again, to be really clear, we aren't shutting down any clients, even ones focused on the mainstream consumer experience. However, if you're going to build a client, we would like to see more of them like CoTweet that focus on a specific audience with specific needs not addressed by the core Twitter clients. BAD third-party clients don't compete with Twitter at all. They just don't have users. People don't use
Re: [twitter-dev] Hoping to clear my confusion about Twitter's announcement
Tim, sorry for taking so long to follow up. Responses inline below... -- Ryan Sarver @rsarver http://twitter.com/rsarver On Mon, Mar 14, 2011 at 4:39 PM, Tim Haines tmhai...@gmail.com wrote: Hey Ryan, Raffi, Taylor, Matt, and other Twitter staff, I've been confused about Ryan's post, and some of the follow up comments. Some of the tweets I've seen since have been reassuring that my original interpretation of Ryan's email was inaccurate. I thought you were saying 'no new client apps allowed', and I'm very relieved to hear I was wrong. I wanted to follow up with a few more questions and comments to make sure I understand Twitter's message correctly. Twitter staff, if I have anything wrong here, please correct, or rephrase to be more accurate. Please excuse the length of this and the number of questions at the end of the email. Changing the API rules is changing the contract we have, and as I'm so invested in the ecosystem (my family's livelihood now depends on it), I want to be completely sure I understand what the new contract is that you're introducing. First off, some background. Ryan said that developers are welcome to develop things that Twitter has said developers shouldn't be doing - shouldn't is guidance only, and not a prohibition. Twitter will only interfere with applications if they break the API TOS. Tweets related to this (clicking on the last one and viewing the thread is easiest): - https://twitter.com/joestump/status/47094929796759552 - https://twitter.com/rsarver/status/47095346899320832 - https://twitter.com/timhaines/status/47096379306291203 - https://twitter.com/rsarver/status/47096690288771072 - https://twitter.com/timhaines/status/47097497679708160 - https://twitter.com/rsarver/status/47097681591545856 Furthermore, the most disturbing paragraph for me in Ryan's announcement: If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service. This and the preceding paragraph together could be interpreted to mean that developers aren't allowed to build NEW client apps. According to the tweets above, they are allowed, but Twitter is advising developers that they should focus their efforts elsewhere. Likewise, existing applications will be held to high standards. As Ryan clarified in his tweets, these applications won't be interfered with unless they break the API TOS. So all told, the email itself doesn't introduce anything new rulewise; you can do anything you want within the API TOS, but if you break the API TOS you'll potentially have your app revoked. No change here. You won't be applying a subjective 'high standard' or 'high bar' and revoking an app unless it breaks the API TOS. Phew! You are remaining an open API, within the confines of your stated rules. However, the email was accompanied with changes to the API TOS (of course Twitter can make any change to the API TOS at any time - including adding further restrictions in the future). This round of changes included amongst other things, the addition of section I.5, adding restrictions to what client applications may and may not do. For the purposes of this email, I'm considering my own application, Favstar, a client. While it doesn't allow you to tweet at the moment, it will in the coming months, therefore meeting the criteria specified in the API TOS for Favstar to be regarded as a client. I understand that for the purposes of this email you are considering Favstar a client, but it doesn't actually fall within the description of a client -- even if you add the ability to tweet. You are not focused on solely rendering the user's home_timeline to them. Obviously, it is difficult to nail down the exact requirements that make it a client, but we're happy to work with developers to figure out where the lines are. So with that being said, it's going to be hard to answer hypothetical questions, but I'll do my best by trying to understand your intention. My questions: 5a: Your Client must use the Twitter API as the sole source for features that are substantially similar to functionality offered by Twitter. Some examples include trending topics, who to follow, and suggested user lists. *Question re 5a:* Favstar has for a long time offered 'suggested user lists' in the form of it's popular page ( http://favstar.fm/popular-on-twitter-by-tweets-with-50-favorites) Is this feature now in breach of the API TOS? If it is in breach, does this place Favstar in breach until the feature is removed? If you were a client, yes *Question re 5a:* If I was to add features that surfaced 'popular themes' found in tweets that Favstar collects, would this be considered similar to Trending topics
Re: [twitter-dev] Please hire a developer relations manager
Adam, I appreciate the email and think you raise some great points. It's all stuff that we aspire to be able to do and things that I think foster great developer ecosystems. We are currently growing the developer advocate team to get poor Matt and Taylor some help ( https://twitter.com/job.html?jvi=o5DxVfwU,Job). Please send along any recommendations of people you think would be a great fit for the role. We have a few more people starting in two months which I think will make a big difference. Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Mon, Mar 14, 2011 at 6:44 AM, Adam Green 140...@gmail.com wrote: First of all, I honestly believe that Twitter HQ values developers and appreciates their contribution. That is why I decided to devote myself to this area a couple of years ago. I was amazed that when a dev reported a problem the engineer responsible replied here and tried to solve it. That is better than any big product I know of today. That is why you have so many developers putting in all this work. I also believe that the last few announcements from Ryan and others have been the worst examples of third party developer management I have seen in 30 years in this business. I can see what Ryan wanted to accomplish in his latest message. He wanted to provide guidance. He ended up telling us that Twitter no longer wanted anyone to build clients, didn't explain clearly what a client meant to him, and pointed out that hundreds of apps that fail to meet his undefined high bar were cut off every week. Not good. Sorry, Ryan. You are right. You are not good at communicating with third party developers. At least not in written form. You look like a very cool guy with a lot of personal charm. Maybe it works better in person. You should spend some time talking directly to developers in small groups. It might help you develop some canned responses that work. Here is a simple way this could have been prevented. If you had a developer relations person with experience and skills in dealing with third party developers, who have completely different motivations from in-house coders, he or she could have quietly passed around a draft of what you wanted to say. This would have gotten very strong negative reactions. You would have been able to reformulate it to strip out the implied threats and turn it into a positive roadmap. It could have been framed as Here are some areas we promise to leave open for developers. If you work here, we will give you all kinds of extra support and promotion. Here is another simple way this could have been prevented. Create an advisory board of developers. Rotate people through it every 6-12 months. Let them vet announcements in advance. Let them respond to the questions. It works in every other company I have worked with. Here is what could be done instead of these repeated bombs you keep dropping on the community. Give people a present. Announce that you will use some of your precious ad space to promote third party apps, and not just the ones with millions of dollars of VC who happen to work in your building. Find new ways to rev share with developers. Offer all expense paid trips to select developers to visit your office for a day to hang out. HOLD A DEVELOPERS CONFERENCE. There are many other things a good developer relations person could do. Talk to Guy. That is how he started for Apple. One last thing. Give this developer relations person a seat at the table when big decisions are made. I can read lots of signals, like this high bar nonsense, that there are negative attitudes inside Twitter towards developers. They are a pain in the ass. Yes. But they do hundreds of millions of dollars in development and promotion for you for free. Hire someone good for $100K+. Give them a million dollar budget to really take care of developers and run conferences and get togethers around the world. It will pay off many times over. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: consistency and ecosystem opportunities
Dewald, sorry if this isn't clear. The intent is to allow developers to still post to other 3rd party networks like Facebook, Identica, LinkedIn, etc. What we don't want to allow is for a client to use our content to build their own competing status service and by sending content to services that the user did not intend to send them to. Users trust us with their content and we want them to have an idea of where the content goes and how it is going to be used. Hope that helps clarify. Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Mon, Mar 14, 2011 at 8:43 AM, Dewald Pretorius dpr...@gmail.com wrote: Taylor, Would you mind taking a stab at clarifying Section 5.E of the new TOS, which reads, You may not use Twitter Content or other data collected from end users of your Client to create or maintain a separate status update or social network database or service. It appears to say that a Client is not allowed to offer its users the ability to create status updates on other services (StatusNet, Facebook, etc.). Had it not been for the or other data collected from end users I would have interpreted it that one cannot use any Twitter Content (user data and tweets obtained via the Twitter API) and feed that Twitter Data into other and/or competing social network platforms. But, or other data collected from end users seems to suggest that one cannot so much as offer any support for any other and/ or competing social network platform. Meaning, if you have a Client, you can support Twitter OR Everything Else, not both. On Mar 14, 11:12 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Adam, Thanks for your comments as always. I can help clarify a bit around how clients will be held to higher standards. Criteria we may examine include: is the application in tune with the spirit of the developer guidelines? Does the application refrain from storing username password if it's using xAuth? Are tweets displayed with the proper attribution? Are the actions presented for the tweet appropriate in respect to it being a tweet? Does the application frame portions of our mobile site? Does it store non-public user data in a public way? Does the application provide a privacy policy? Is the client application paying for installation on mobile carriers? The new terms also offer some examples that are reasonably specific: A. Your Client must use the Twitter API as the sole source for features that are substantially similar to functionality offered by Twitter. Some examples include trending topics, who to follow, and suggested user lists. B. You may not pay, or offer to pay, third parties for distribution of your Client. This includes offering compensation for downloads (other than transactional fees), pre-installations, or other mechanisms of traffic acquisition. C. Your Client cannot frame or otherwise reproduce significant portions of the Twitter service. You should display Twitter Content from the Twitter API. D. Do not store non-public user profile data or content. E. You may not use Twitter Content or other data collected from end users of your Client to create or maintain a separate status update or social network database or service Using a Twitter client is like using an extension of Twitter, and though the user interfaces may change we want to ensure that the user experience is consistent, whether it's consistency in the actions a user can perform with a Tweet, the way their private information is treated, or how slowly, quickly, and with what tact advertising flows or does not flow through the network. Taylor On Sun, Mar 13, 2011 at 9:55 PM, Adam Green 140...@gmail.com wrote: Yes! Transparency! That is what we are really craving. That is the subtext for every developer responding to this thread. What we all want is transparency about being shut down. Why does Twitter revoke literally hundreds of API tokens / apps a week as Ryan said? Is it for something obvious, like pumping out thousand of spam tweets or abusive follows, or is it for something innocent, like not putting the right text on a tweet button? I have never seen a description of an app that was blocked, except for a few loons like Edward H. What if you told us about apps that get blocked as examples, and explain what they did wrong? You don't even have to identify them by name. Just explain exactly what type of transgressions are causing rejection. That could calm people down. Who doesn't meet the high bar and why? I know high bar has a lot of meaning to you Twitter guys, since you all use the same term (a real example of groupthink, BTW), but it means nothing to us. Tell us where this high bar is exactly, by showing examples of not reaching it. Then we can learn and improve, rather than guessing at what you mean. Nobody
Re: [twitter-dev] Re: Requesting increased access levels for Streaming API
Ed, I'm not sure what you mean by: You need to get *all* your users to *explicitly* authorize the application's *exact* usage of their data! Of course! that is exactly what we are saying and I'm not sure if you're really saying you shouldn't get the user's authorization as that doesn't make sense. I don't expect everyone to be able to use User Streams or Site Streams, but that is why the REST API exists. -- Ryan Sarver @rsarver http://twitter.com/rsarver On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), Ryan Sarver (@rsarver) ryan.sar...@gmail.com wrote: Also as we stated before, you can use User Streams or Site Streams and get more data by getting more users to authorize your application. Ryan, it's not as simple as getting more users to authorize your application. You need to get *all* your users to *explicitly* authorize the application's *exact* usage of their data! Users tend not to read the fine print. I'd hate to see some data collection / analytics application make some assumptions based on the implicit openness of the tweet stream and then get nailed by a bunch of angry users. Angry users tend to write to their Congressmen and Senators. ;-) Managing a *single* user's User Streams feed is a relatively straightforward coding task - I've got a smallish Perl script that can do it for my own account. Managing multiple users' Site Streams is a much more complex endeavor, and to use that mechanism for a data collection / analytics application is ludicrous IMHO. Somehow, the notion of the right tool for the job seems to have been ignored. ;-) -- http://twitter.com/znmeb http://borasky-research.net A mathematician is a device for turning coffee into theorems. -- Paul Erdős -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Requesting increased access levels for Streaming API
We should have been more clear, but elevated levels of streaming was included in the previous statement about ending the whitelisting program. There are open levels for each stream or you can contact Gnip if you are looking for elevated access for the purposes of data analysis. Also as we stated before, you can use User Streams or Site Streams and get more data by getting more users to authorize your application. Hope that helps clarify. Best, Ryan On Mar 16, 1:47 am, Scott Wilcox sc...@dor.ky wrote: Highly unlikely. At the present time it's either the Streaming API or using GNIP. I don't believe there are any use cases where they would provide you with elevated Streaming API access to the level you desire. Sent from my iPhone On 16 Mar 2011, at 04:23, manusis ra...@manusis.com wrote: Yeah I went through gnip in detail but their pricing is excessively expensive especially when I care only about twitter data and not the hundred other sources that they provide. I was hoping that if not partner track, twitter might be open to give at least restricted track access to developers. On Mar 15, 8:10 pm, hax0rsteve hax0rc...@btinternet.com wrote: From that same post :http://groups.google.com/group/twitter-development-talk/browse_thread... Developers interested in elevated access to the Twitter stream for the purpose of research or analytics can contact our partner Gnip for more information. Fromhttp://gnip.com/ Gnip and Twitter have partnered to bring more Twitter feeds to Gnip customers. Check out Power Track for 100% guaranteed coverage firehose filtering and all commercial Twitter data, only from Gnip. Fromhttp://gnip.com/twitter/power-track • The only feed of its kind: Twitter firehose filtering with 100% coverage guaranteed • Boolean operators, unwound URLs, and matching within unwound URLs supported • Keyword, username, and location filtering supported • Unlimited capacity: no restrictions on filter parameters or results volume - Premium Feed • Pay for what you get - pricing depends on Tweet volume delivered - Premium Feed • Contact i...@gnip.com for more information - Premium Feed HTH On 15 Mar 2011, at 15:04, manusis wrote: Thanks Augusto. But the same thread indicates that tools like Streaming API will replace whitelisting. So it does not make sense for me for Streaming API to put under the same umbrella as whitelisting. Since then, we've added new, more efficient tools for developers, including lookups, ID lists, authentication and the Streaming API. Instead of whitelisting, developers can use these tools to create applications and integrate with the Twitter platform. On Mar 15, 7:41 pm, Augusto Santos augu...@gemeos.org wrote: I think the answer is you never will. This kind of benefit might follow the same rules that whitelist, that will no longer be supported just as the thread below said.http://groups.google.com/group/twitter-development-talk/browse_thread... On Tue, Mar 15, 2011 at 6:58 AM, manusis ra...@manusis.com wrote: The streaming API mentions about different access roles but does not indicate how one could apply for them. The default access level allows up to 400 track keywords, 5,000 follow userids and 25 0.1-360 degree location boxes. Increased access levels allow 100,000 follow userids (“shadow” role), 400,000 follow userids (“birddog” role), 10,000 track keywords (“restricted track” role), 200,000 track keywords (“partner track” role), and 200 0.1-360 degree location boxes (“locRestricted” role). Increased track access levels also pass a higher proportion of statuses before limiting the stream. For our product, we need shadow and partner track access roles. Could somebody shed any light on how one could apply for the increased access levels? Thanks, Rajiv -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- 氣 -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list Change your membership to this group:http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list Change your membership to this group:http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:
Re: [twitter-dev] Hoping to clear my confusion about Twitter's announcement
Tim, thanks for taking the time to write up such an epic email. Give me some time to parse through it so I can follow up on all the points. Also, not sure what happened to the thread on api-announce, but I reposted linking to this thread so people can still find it. Best, Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Mon, Mar 14, 2011 at 11:39 PM, Tim Haines tmhai...@gmail.com wrote: Hey Ryan, Raffi, Taylor, Matt, and other Twitter staff, I've been confused about Ryan's post, and some of the follow up comments. Some of the tweets I've seen since have been reassuring that my original interpretation of Ryan's email was inaccurate. I thought you were saying 'no new client apps allowed', and I'm very relieved to hear I was wrong. I wanted to follow up with a few more questions and comments to make sure I understand Twitter's message correctly. Twitter staff, if I have anything wrong here, please correct, or rephrase to be more accurate. Please excuse the length of this and the number of questions at the end of the email. Changing the API rules is changing the contract we have, and as I'm so invested in the ecosystem (my family's livelihood now depends on it), I want to be completely sure I understand what the new contract is that you're introducing. First off, some background. Ryan said that developers are welcome to develop things that Twitter has said developers shouldn't be doing - shouldn't is guidance only, and not a prohibition. Twitter will only interfere with applications if they break the API TOS. Tweets related to this (clicking on the last one and viewing the thread is easiest): - https://twitter.com/joestump/status/47094929796759552 - https://twitter.com/rsarver/status/47095346899320832 - https://twitter.com/timhaines/status/47096379306291203 - https://twitter.com/rsarver/status/47096690288771072 - https://twitter.com/timhaines/status/47097497679708160 - https://twitter.com/rsarver/status/47097681591545856 Furthermore, the most disturbing paragraph for me in Ryan's announcement: If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service. This and the preceding paragraph together could be interpreted to mean that developers aren't allowed to build NEW client apps. According to the tweets above, they are allowed, but Twitter is advising developers that they should focus their efforts elsewhere. Likewise, existing applications will be held to high standards. As Ryan clarified in his tweets, these applications won't be interfered with unless they break the API TOS. So all told, the email itself doesn't introduce anything new rulewise; you can do anything you want within the API TOS, but if you break the API TOS you'll potentially have your app revoked. No change here. You won't be applying a subjective 'high standard' or 'high bar' and revoking an app unless it breaks the API TOS. Phew! You are remaining an open API, within the confines of your stated rules. However, the email was accompanied with changes to the API TOS (of course Twitter can make any change to the API TOS at any time - including adding further restrictions in the future). This round of changes included amongst other things, the addition of section I.5, adding restrictions to what client applications may and may not do. For the purposes of this email, I'm considering my own application, Favstar, a client. While it doesn't allow you to tweet at the moment, it will in the coming months, therefore meeting the criteria specified in the API TOS for Favstar to be regarded as a client. My questions: 5a: Your Client must use the Twitter API as the sole source for features that are substantially similar to functionality offered by Twitter. Some examples include trending topics, who to follow, and suggested user lists. *Question re 5a:* Favstar has for a long time offered 'suggested user lists' in the form of it's popular page ( http://favstar.fm/popular-on-twitter-by-tweets-with-50-favorites) Is this feature now in breach of the API TOS? If it is in breach, does this place Favstar in breach until the feature is removed? *Question re 5a:* If I was to add features that surfaced 'popular themes' found in tweets that Favstar collects, would this be considered similar to Trending topics, and put Favstar in breach of the API TOS? *Question re 5a:* Favstar users can buy 'bonus features', and receive a slew of extra features. I've recently started promoting these users on the site. If follow buttons were added to their avatar's in the places of promotion, could this be considered as a 'who to follow' feature that would put Favstar in breach of the API TOS? 5c: Your
Re: [twitter-dev] Re: consistency and ecosystem opportunities
Adam, I don't know how else to make this any more clear. As long as you stay within the rules, your app will not get shut off. We would like to see, and recommend that, developers focus on bigger opportunities with more potential than writing another consumer client app. -- Ryan Sarver @rsarver http://twitter.com/rsarver On Mon, Mar 14, 2011 at 9:28 AM, Adam Green 140...@gmail.com wrote: But you will allow it, right? Even if it is thinking small, it will not be blocked? That is our problem. We can't separate business advice from a warning to prepare to be cut off. We can't help watching the hand that holds the kill switch. It makes it hard to hear what you say. Have patience, and keep explaining please. If something will not cause a ban, then say this explicitly to us. Don't just think it was implied. On Mon, Mar 14, 2011 at 11:20 AM, Raffi Krikorian ra...@twitter.comwrote: my statement here was not providing small on the size of the company, but rather, small on the size of the idea. to re-iterate, making a piece of software that simply renders home_timeline is thinking too small. On Sun, Mar 13, 2011 at 6:21 PM, Lil Peck lilp...@gmail.com wrote: On Sun, Mar 13, 2011 at 7:45 PM, @siculars sicul...@gmail.com wrote: @raffi @rsarver, I wrote up my two cents earlier, http://siculars.posterous.com/twitter-monoculture. I just don't appreciate the direction you all are going in. @raffi, I spoke with you at the CU recruiting event a few weeks back and I got to tell you that if I were asked I would tell those kids to reconsider working at twitter and possibly consider a Twitter competitor. you say building clients is ... Thinking too small I would say your policy change is thinking small and alienating your ardent supporters. To which I would add, what is Twitter to arbitrate that which is and is not too small? Has Twitter subscribed to the fallacious bigger is always better philosophy? How small is too small? Less than $25 million in startup funds? OR One creative, fun loving person and their sweat equity? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Raffi Krikorian Twitter, Application Services http://twitter.com/raffi -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: consistency and ecosystem opportunities
To be clear, Raffi is clearly articulating the situation. It's a complex thing and we can't expect to get it perfectly right the first time, so the dialogue and questions are great. Raffi is also a much better communicator than I am :) -- Ryan Sarver @rsarver http://twitter.com/rsarver On Sun, Mar 13, 2011 at 4:04 PM, Craig cpa...@gmail.com wrote: Yes, Raffi's posts have made me feel a *lot* better about all of this. I hope his comments will be reflected in some way by an 'official' message from Twitter. It's not that I don't believe Raffi, I do, but it bothers me that Ryan or someone hasn't yet come back to explicitly confirm Raffi's comments (which, it should be noted, came with a disclaimer). -Craig On 13 March 2011 11:38, Rich rhyl...@gmail.com wrote: Similar situation, although Raffi's response above is slightly more reassuring. On Mar 13, 3:34 pm, Jef Poskanzer jef.poskan...@gmail.com wrote: I have a set of apps that basically just reproduces the official Twitter user experience, exactly what Twitter says we should not do. However, I add value by running on a platform that Twitter does not support and is unlikely to ever support. I believe this should be allowed and encouraged and would appreciate a statement to that effect. Furthermore, this is probably not the only exception to the don't just reproduce Twitter rule. Please consider that there may be entire areas of innovation that you have not thought of - that's why it's called innovation. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: consistency and ecosystem opportunities
Mike, a client is one that recreates the twitter experience, or in your words the primary experience. So I don't consider Instagram or Foursquare in that group. It's apps that render a user their timeline. Apps that post into Twitter are great and explicitly called out at the bottom of the email. Hope that helps clarify. Best, Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Fri, Mar 11, 2011 at 9:09 PM, Mike Champion mike.champ...@gmail.comwrote: Thanks for the clarification Ryan. Two questions: 1) Do you have a clear definition of what counts as a Twitter client? Is it any app/service that posts updates to Twitter, including apps like twitterfeed and Instapaper? Or is it only those apps that are primarily clients? I'm certainly familiar with the challenge of classifying apps ;) but wanted to know who will be covered by the ToS Section 1.5 and how you think about clients given Twitter's updated stance. 2) In section 1.5.A of the ToS it says: Your Client must use the Twitter API as the sole source for features that are substantially similar to functionality offered by Twitter. Some examples include trending topics, who to follow, and suggested user lists. Is the Who to follow functionality available via API from Twitter for clients that want to offer this? I wasn't aware that it been released as API but may have missed it on dev.twitter.com. Thanks, -mike On Mar 11, 3:47 pm, Eric Mill kproject...@gmail.com wrote: More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no. We need to ensure users can interact with Twitter the same way everywhere. I'm not sure you can say these things and simultaneously try to say you have a welcoming developer environment. All third party Twitter developers, no matter what they make, are now walking on eggshells, constantly at risk of offending Twitter's ideas of how users should interact with Twitter. You may feel you need this consistency, but you don't. You want it, and are willing to make tradeoffs to get it. I just hope you realize how big those tradeoffs are, and how chilling it is for Twitter to decide that only certain kinds of innovation on the Twitter API are welcome. -- Eric -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: consistency and ecosystem opportunities
David, we are specifically talking about consumer clients. HootSuite and Seesmic are focused on a more enterprise or marketer audience as I called out at the bottom of the email. Best, Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Sat, Mar 12, 2011 at 12:32 AM, David W d_wy...@yahoo.com wrote: It seems a little confusing that you're basically saying don't build any more Twitter clients and then call out the likes of Hoot Suite and Seesmic as being examples of what people should be doing. At heart they're just Twitter clients (that we shouldn't build any more?) They also appear to be conflict with section 5e of the Ts Cs: You may not use Twitter Content or other data collected from end users of your Client to create or maintain a separate status update or social network database or service. I guess what confuses me most, is the motivation behind this announcement? I mean sure, no-one wants apps out there that take advantage of end users and give them a rough ride, but as you said yourself 90% of users aren't getting that experience and as someone else said; good apps will always bubble to the top. I think it's incredibly disappointing to hear Twitter tell dev's not to create clients any more. No developer sets out to create a bad Twitter client. They set out to improve the Twitter experience, because they believe they can and generally because they love Twitter. Arguably Twitter wouldn't be where it is today if it weren't for those that did exactly that. Unless we've all misunderstood what's been said here, then I'd question investing any time or money into the focusing on what are, today, areas outside the mainstream consumer client experience. Sure go ahead and innovate in the areas Twitter tells you you're allowed to... for now. What happens when Twitter sees the new innovation you've just discovered is really popular? Do we get another announcement telling dev's not to develop that stuff any more? Like I say, I hope we've all misunderstood the message here (I really do). I've no beef with the Ts Cs. But please don't tell people to stop developing clients that people work hard on and that users love. On Mar 11, 8:18 pm, Ryan Sarver rsar...@twitter.com wrote: Hey all, I’d like to give you an update about the state of the Twitter Platform and hopefully provide some much requested guidance. Since this time last year, Twitter use has skyrocketed. We’ve grown from 48 million to 140 million tweets a day and we’re registering new accounts at an all-time record. This massive base of users, publishers, and businesses is a giant playground for developers to build their own businesses on, and this means the opportunity has grown for everyone. With more people joining Twitter and accessing the service in multiple ways, a consistent user experience is more crucial than ever. As we talked about last April, this was our motivation for buying Tweetie and developing our own official iPhone app. It is the reason why we have developed official apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on their Twitter for Blackberry app. As a result, the top five ways that people access Twitter are official Twitter apps. Still, our user research shows that consumers continue to be confused by the different ways that a fractured landscape of third-party Twitter clients display tweets and let users interact with core Twitter functions. For example, people get confused by websites or clients that display tweets in a way that doesn’t follow our design guidelines, or when services put their own verbs on tweets instead of the ones used on Twitter. Similarly, a number of third-party consumer clients use their own versions of suggested users, trends, and other data streams, confusing users in our network even more. Users should be able to view, retweet, and reply to @nytimes’ tweets the same way; see the same profile information about @whitehouse; and be able to join in the discussion around the same trending topics as everyone else across Twitter. *A Consistent User Experience* Twitter is a network, and its network effects are driven by users seeing and contributing to the network’s conversations. We need to ensure users can interact with Twitter the same way everywhere. Specifically: - *The mainstream consumer client experience*. Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets. If there are too many ways to use Twitter that are inconsistent with one another, we risk diffusing the user experience. In addition, a number of client applications have repeatedly violated Twitter’s Terms of Service, including our user privacy policy. This demonstrates the risks associated
Re: [twitter-dev] consistency and ecosystem opportunities
Adam, that is a totally incorrect characterization of the companies I listed in the email. A ton of those companies -- CoTweet, Klout, HootSuite, Socialflow -- sprung out of the ecosystem and were started on nights and weekends with no funding. Of course they have gotten some funding now as investors see them as great potential businesses. Of course statuses/update is still allowed. As is statuses/user_timeline. We've added more policies and given guidance that we don't think there is a business in building consumer clients, but none of the APIs have changed. -- Ryan Sarver @rsarver http://twitter.com/rsarver On Sun, Mar 13, 2011 at 12:40 AM, Adam Green 140...@gmail.com wrote: I agree, Scott. Ryan didn't say you can't post tweets, but everyone heard that. Every tech blog repeated it. Ryan should take a minute and explain that it isn't true. That much would help a lot. He led by saying don't build a client. That is where people stopped reading. I don't think he meant to tell people that apps can't tweet, but he did give that impression. Now he should come back and say, Sorry guys. I gave you the wrong impression. Here are specifically the things you can still do. Don't just point to companies with $10M in VC funds each and say No problem, just be like them. These are API developers. Say it in terms of the API. Exactly which API calls are still allowed. If he says statuses/update is still allowed, then that answers the question. There is no ambiguity. As for Twitter being free. Yes. The API is, but denying the value that products like Tweetdeck gave Twitter *for free* is denying the reality of how Twitter got to where it is. It is called a partnership. They give us raw materials, we add value to them. We all benefit. On Sat, Mar 12, 2011 at 7:28 PM, Scott Wilcox sc...@dor.ky wrote: Hello, For a few days now I've read what people have said in reply to the update from Ryan. There are some crazy reactions and responses to what Ryan has said. In essence, the entire reaction is my opinion is completely overblown. Not in any sense what-so-ever have Twitter said that you can no longer post updates on behalf of users. Its ludicrous to suggest so. What they have have said (and in my opinion - quite clearly) is that it is better to direct your time and effort into a product that is not just a simple client and does more than just provide viewing and posting of tweets. There are so many half-arsed clients out there that do little more than just show and post tweets. If by chance a user was to use these low grade applications as their first experience of Twitter, it would probably put them off using it in the long term. I do fully believe that is why they have released their own branded clients for iOS, Macs and other devices. It provides a consistent experience for the end-users. The other thing that people seem to completely overlook is that Twitter are providing a freely accessible API at no charge to developers. It pains me to see so many developers standing the moral high ground. If you were paying for access to a service or product and it changes, you have a very valid reason to complain. To complain about a service provided free of charge for you to use at the end of the day frustrates me to no end. No single developer has a god given right to have access to the API, perhaps that should be remembered. Scott. On 13 Mar 2011, at 00:16, Adam Green wrote: Interesting that neither Ryan or anyone else from Twitter has replied once to any of the questions here, (way to go on showing your interest in the developer community, Ryan), so I'll address this question to everyone else in the group. I don't read Ryan's message as demanding that apps are no longer allowed to send tweets on behalf of users. Is that supposed to be what he said? I think he is saying that apps should be more than *just* clients that let you read and post tweets. How to tell the difference, I have no idea, but I think in Ryan's mind there is a difference. I'll ask it as clearly as I can. Is it still allowed for an app to accept a tweet from a user and post it into their account? Is the /statuses/update api call still allowed in an app? Let's not wait for Twitter to respond, since they clearly don't want to any longer. Let's try and figure this out ourselves. What does everyone think? Can apps still send tweets? If yes, there is still a market for Twitter API developers. If not, the Twitter API is over. It is that simple. Maybe Ryan or anyone from Twitter can also find the time to answer this. On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands duane.roela...@gmail.com wrote: Wow. Thanks for getting so many people interested in Twitter. Now get lost. This is appalling. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p
[twitter-dev] consistency and ecosystem opportunities
Hey all, I’d like to give you an update about the state of the Twitter Platform and hopefully provide some much requested guidance. Since this time last year, Twitter use has skyrocketed. We’ve grown from 48 million to 140 million tweets a day and we’re registering new accounts at an all-time record. This massive base of users, publishers, and businesses is a giant playground for developers to build their own businesses on, and this means the opportunity has grown for everyone. With more people joining Twitter and accessing the service in multiple ways, a consistent user experience is more crucial than ever. As we talked about last April, this was our motivation for buying Tweetie and developing our own official iPhone app. It is the reason why we have developed official apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on their Twitter for Blackberry app. As a result, the top five ways that people access Twitter are official Twitter apps. Still, our user research shows that consumers continue to be confused by the different ways that a fractured landscape of third-party Twitter clients display tweets and let users interact with core Twitter functions. For example, people get confused by websites or clients that display tweets in a way that doesn’t follow our design guidelines, or when services put their own verbs on tweets instead of the ones used on Twitter. Similarly, a number of third-party consumer clients use their own versions of suggested users, trends, and other data streams, confusing users in our network even more. Users should be able to view, retweet, and reply to @nytimes’ tweets the same way; see the same profile information about @whitehouse; and be able to join in the discussion around the same trending topics as everyone else across Twitter. *A Consistent User Experience* Twitter is a network, and its network effects are driven by users seeing and contributing to the network’s conversations. We need to ensure users can interact with Twitter the same way everywhere. Specifically: - *The mainstream consumer client experience*. Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets. If there are too many ways to use Twitter that are inconsistent with one another, we risk diffusing the user experience. In addition, a number of client applications have repeatedly violated Twitter’s Terms of Service, including our user privacy policy. This demonstrates the risks associated with outsourcing the Twitter user experience to third parties. Twitter has to revoke literally hundreds of API tokens / apps a week as part of our trust and safety efforts, in order to protect the user experience on our platform. - *Display of tweets in 3rd-party services*. We need to ensure that tweets, and tweet actions, are rendered in a consistent way so that people have the same experience with tweets no matter where they are. For example, some developers display “comment”, “like”, or other terms with tweets instead of “follow, favorite, retweet, reply” - thus changing the core functions of a tweet. With this in mind, we’ve updated our Terms of Service: http://dev.twitter.com/pages/api_terms. *The Opportunity for Developers* Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter. More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no. If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service. We have spoken with the major client applications in the Twitter ecosystem about these needs on an ongoing basis, and will continue to ensure a high bar is maintained. As we point out above, we need to move to a less fragmented world, where every user can experience Twitter in a consistent way. This is already happening organically - the number and market share of consumer client apps that are not owned or operated by Twitter has been shrinking. According to our data, 90% of active Twitter users use official Twitter apps on a monthly basis. In contrast, the number of successful applications and companies in the Twitter ecosystem that focus on areas outside of the mainstream consumer client experience has grown quickly, and this is a trend we want to continue to support and help grow. Twitter will always be a platform on which a smart developer with a great idea and some cool technology can build a great company of his or her own. And, with record user growth, there has never been a better time to build into Twitter. Some
[twitter-dev] Update on Whitelisting
Beginning today, Twitter will no longer grant whitelisting requests. We will continue to allow whitelisting privileges for previously approved applications; however any unanswered requests recently submitted to Twitter will not be granted whitelist access. Twitter whitelisting was originally created as a way to allow developers to request large amounts of data through the REST API. It provided developers with an increase from 150 to 20,000 requests per hour, at a time when the API had few bulk request options and the Streaming API was not yet available. Since then, we've added new, more efficient tools for developers, including lookups, ID lists, authentication and the Streaming API. Instead of whitelisting, developers can use these tools to create applications and integrate with the Twitter platform. As always, we are committed to fostering an ecosystem that delivers value to Twitter users. Access to Twitter APIs scales as an application grows its userbase. With authentication, an application can make 350 GET requests on a user’s behalf every hour. This means that for every user of your service, you can request their timelines, followers, friends, lists and saved searches up to 350 times per hour. Actions such as Tweeting, Favoriting, Retweeting and Following do not count towards this 350 limit. Using authentication on every request is recommended, so that you are not affected by other developers who share an IP address with you. We also want to acknowledge that there are going to be some things that developers want to do that just aren’t supported by the platform. Rather than granting additional privileges to accommodate those requests, we encourage developers to focus on what's possible within the rich variety of integration options already provided. Developers interested in elevated access to the Twitter stream for the purpose of research or analytics can contact our partner Gnip for more information. As always, we are here to answer questions, and help you build applications and services that offer value to users. Ryan -- Ryan Sarver @rsarver -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Update on Whitelisting
Orian, You should definitely plan on working within 350/hr for the forseeable future. FWIW, we have watched #newtwitter usage and an average session uses between 80-120 rq/hr. Hope that helps clarify. Best, Ryan -- Ryan Sarver @rsarver http://twitter.com/rsarver On Thu, Feb 10, 2011 at 6:17 PM, Orian Marx (@orian) or...@orianmarx.comwrote: Ryan et al, thanks for the update on this. Shall we also take this to mean 350 is the definitive cap on rate limits for the foreseeable future? This certainly seems to be implied but since the spirit of this update seems to be to remove ambiguity, I think a clear statement that Twitter is no longer planning on gradually increasing rate limits, as has been stated many times in the past, would be appreciated. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Twitter + Gnip Partnership
Spritzer is currently at 1% of the Firehose, but as the docs say it's subject to change without notice On Sun, Nov 21, 2010 at 10:18 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ryan Sarver rsar...@twitter.com: Many of you may wonder what this means for elevated access and whitelisting requests. Our default levels like Spritzer, Follow and Track will not be changing, and will remain free and available directly from Twitter. Companies and developers are encouraged to begin development with these free APIs, available at http://dev.twitter.com/pages/streaming_api. Is Spritzer still 1% of the Firehose? Since the status IDs are no longer sequential, the previous obvious sampling algorithm - status ID mod 100 == 0 - no longer will work. -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Twitter + Gnip Partnership
The basic level of statuses/filter will remain unchanged On Fri, Nov 19, 2010 at 12:06 AM, Scott J sc...@globalizenetworks.com wrote: I would like to know the answer to this as well. What will the limits be on the statuses/filter? On Nov 17, 9:44 am, Dewald Pretorius dpr...@gmail.com wrote: Ryan, The Gnip blog post states: [QUOTE]Twitter Decahose. This volume-based product is comprised of 10% of the full firehose. Starting today, developers who want to access this sample rate will access it via Gnip instead of Twitter. Twitter will also begin to transition non-display developers with existing Twitter Gardenhose access over to Gnip.[/QUOTE] How does this affect the basic statuses/sample method of the Streaming API? Are you discontinuing it? If so, when? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Twitter + Gnip Partnership
Companies have leveraged Twitter’s open API to analyze and report on conversations and sentiment across the network since its inception. These products have been indispensable in helping brands, marketers and businesses engage with their customers on Twitter. This is an area we want to support more fully, and today we are excited to announce a partnership with Gnip to develop and market data products specifically for these analysis and non-display companies. Gnip will sublicense access to our public Tweets to developers interested in analyzing large amounts of Twitter data. Over the past year we have spoken with many companies and entrepreneurs throughout the ecosystem who need easier access to more data. In particular, companies building analysis and non-display products have asked us for greater volume and coverage. Our partnership with Gnip is built to address this need. Gnip will focus exclusively on creating products to meet the existing and emerging demands of companies creating non-display products. Check out Gnip’s blog to learn more and to see details about their initial Twitter data products: http://blog.gnip.com/gnip-twitter-partnership/. Many of you may wonder what this means for elevated access and whitelisting requests. Our default levels like Spritzer, Follow and Track will not be changing, and will remain free and available directly from Twitter. Companies and developers are encouraged to begin development with these free APIs, available at http://dev.twitter.com/pages/streaming_api. This does affect companies wishing to create products which analyze Tweets and do not display Tweets to end-users. Moving forward, we will begin to encourage these companies needing elevated access for analysis and non-display products to work with Gnip to find the right data products for their commercial needs. We’re excited about this partnership, and the support it offers the data analysis and non-display market. You can learn more about the details and Gnip by visiting http://gnip.com/twitter. Please let me know if you have any questions about how this affects you and your products. To contact Gnip: web: http://gnip.com email: i...@gnip.com twitter: http://twitter.com/gnip Best, Ryan -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Twitter + Gnip Partnership
Dewald, The basic levels of all of the streaming APIs -- Spritzer, Follow, Track -- will remain open, free and direct from us. Elevated levels for non-display use will be served through Gnip. Hope that answers the question. Best, Ryan On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius dpr...@gmail.com wrote: Ryan, The Gnip blog post states: [QUOTE]Twitter Decahose. This volume-based product is comprised of 10% of the full firehose. Starting today, developers who want to access this sample rate will access it via Gnip instead of Twitter. Twitter will also begin to transition non-display developers with existing Twitter Gardenhose access over to Gnip.[/QUOTE] How does this affect the basic statuses/sample method of the Streaming API? Are you discontinuing it? If so, when? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Twitter + Gnip Partnership
Shannon, good questions -- answers inline below... On Wed, Nov 17, 2010 at 12:27 PM, Shannon Clark shannon.cl...@gmail.com wrote: Looking at Gnip's website they have the contact us for pricing links - will Twitter Gnip be making the pricing for the various levels public? They will be published if they aren't already and they are being widely reported through RWW and other outlets. One of the main goal is transparency Will companies that license the data be allowed to, in turn, sell services on top of that data - i.e. will this spark a new generation of products such as Scout Labs (now Lithium) or other analytics tools which are built by companies who have negotiated for full or partial firehose access but which are then used by clients of those companies each of whom will configure different queries and searches to monitor? Companies can definitely build and sell products based on the analysis of the data. A major market for this move is the Social Media Monitoring (SMM) market and we expect that to grow. And on a more technical level will Gnip and Twitter work together to make the transition for developers who might start building/testing a tool using Twitter's free API's but then later migrate to Gnip's commercial feeds as seemless as possible? Will the API calls etc be similar (or identical but with different URL's?) Gnip is offering an exact proxy of our API so that the payloads look the same. You would just need to change the endpoint you are pointing at and (I think) your credentials for accessing the endpoint And a further query - you emphasize that this is for non-display services - does that mean, for example, that an analytics tool built using the new Mentions feed from Gnip cannot display the underlying Tweets that are returned by that feed? This would seem to severely limit the value and utility of such analytics to many businesses (who might want to reply to many of those messages, might want to follow people on Twitter discussing their company/brand/industry/competitors, and in almost all cases will want to view the full Tweet w/rich metadata not just a summarization of #s of tweets etc.) This is really about B2C vs B2B. We expect that the dashboard will want to show tweets and we support that, but it should be for a commercial audience that wouldn't be interested in running Twitter's promoted products. Let me know if that doesn't make sense. And/or would a business focused Twitter client - CoTweet, Hootsuite, Tweetdeck etc be able to offer (perhaps as part of a professional version) such enhanced Mentions feeds and display them within that application? This deal is all about elevated access. CoTweet and Hootsuite are able to operate on the freely available, basic APIs. If however, Hootsuite wanted to get larger volumes of data for analytics, they would want to reach out to Gnip. Hope that answers your questions. Best, Ryan thanks, Shannon (I'm not an active developer at the moment but I am consulting some business clients on a range of social media tools and as analytics and the appropriate use of them is a core part of my recommendations I'm following these developments closely and look forward to I hope new competitors in the analytics space soon) - Real Things - http://realthings.posterous.com/ Slow Brand - http://slowbrand.com Searching for the Moon - http://shannonclark.wordpress.com - cell: 1.510.333.0295 Twitter - rycaut On Wed, Nov 17, 2010 at 10:09 AM, Ryan Sarver rsar...@twitter.com wrote: Dewald, The basic levels of all of the streaming APIs -- Spritzer, Follow, Track -- will remain open, free and direct from us. Elevated levels for non-display use will be served through Gnip. Hope that answers the question. Best, Ryan On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius dpr...@gmail.com wrote: Ryan, The Gnip blog post states: [QUOTE]Twitter Decahose. This volume-based product is comprised of 10% of the full firehose. Starting today, developers who want to access this sample rate will access it via Gnip instead of Twitter. Twitter will also begin to transition non-display developers with existing Twitter Gardenhose access over to Gnip.[/QUOTE] How does this affect the basic statuses/sample method of the Streaming API? Are you discontinuing it? If so, when? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group
Re: [twitter-dev] Re: Twitter + Gnip Partnership
This deal with Gnip is all about *elevated access* you can build whatever product you want (as long as it adheres to the Twitter API Rules) with the basic APIs and basic levels of access. As to the second part of your question we are setting the pricing as to ensure that their sole position isn't exploited. With that being said, you might find the products to be expensive, but we feel this is premium data and we're mostly focused on consumer facing businesses where the business model is promoted products and the data is free to developers. On Wed, Nov 17, 2010 at 12:51 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Ryan, what about User Streams? I'm building something around User Streams but it is a non-display analytics application. Am I at risk for Twitter inserting another business into *my* data stream as well? And I'm curious how some of the other Streaming consumers are going to react to insertion of a monopoly middleman into their data source. I briefly dealt with Gnip a while back and found their API hard to use and their pricing exorbitant. -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos Quoting Ryan Sarver rsar...@twitter.com: Dewald, The basic levels of all of the streaming APIs -- Spritzer, Follow, Track -- will remain open, free and direct from us. Elevated levels for non-display use will be served through Gnip. Hope that answers the question. Best, Ryan On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius dpr...@gmail.com wrote: Ryan, The Gnip blog post states: [QUOTE]Twitter Decahose. This volume-based product is comprised of 10% of the full firehose. Starting today, developers who want to access this sample rate will access it via Gnip instead of Twitter. Twitter will also begin to transition non-display developers with existing Twitter Gardenhose access over to Gnip.[/QUOTE] How does this affect the basic statuses/sample method of the Streaming API? Are you discontinuing it? If so, when? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Twitter + Gnip Partnership
Adam, it's a good question and it really comes down to what you are trying to re-sell. Re-syndication or re-sale of the actual tweets is strictly prohibited and won't change on our end. We are however, ok with reselling of data that results from analysis of the Twitter API. So a great example is Klout. They do a lot of work to determine a user's Klout score by analyzing the Twitter API and the content of tweets. They *are* able to resell their score, but they would not be able to resell the tweets that were used to determine that score. It's nuanced, so let me know if that makes sense. On Wed, Nov 17, 2010 at 12:55 PM, Adam Green 140...@gmail.com wrote: Ryan: Shannon raises a lot of great points, but I'd like to hear more about the issue of reselling data derived from a purchased stream. Right now the TOS says that you can't resell data from the API. I've been telling clients that eventually Twitter will decide to make money from the API, and when that happens there would have to be a way to resell what has been paid for. Now that you are selling access to the API, which I strongly agree with, will you allow a free market to evolve around that by making it possible for Twitter data retailers to grow businesses, as well as wholesalers like Gnip? Please, say yes. I'm hoping an Apple-style, control the distribution channel completely mindset doesn't develop at Twitter. I'm hoping Twitter wants to help the developer ecosystem turn into a true third party market. Letting developers sell data or help clients sell data is essential for that. On Wed, Nov 17, 2010 at 1:27 PM, Shannon Clark shannon.cl...@gmail.com wrote: Looking at Gnip's website they have the contact us for pricing links - will Twitter Gnip be making the pricing for the various levels public? Will companies that license the data be allowed to, in turn, sell services on top of that data - i.e. will this spark a new generation of products such as Scout Labs (now Lithium) or other analytics tools which are built by companies who have negotiated for full or partial firehose access but which are then used by clients of those companies each of whom will configure different queries and searches to monitor? And on a more technical level will Gnip and Twitter work together to make the transition for developers who might start building/testing a tool using Twitter's free API's but then later migrate to Gnip's commercial feeds as seemless as possible? Will the API calls etc be similar (or identical but with different URL's?) And a further query - you emphasize that this is for non-display services - does that mean, for example, that an analytics tool built using the new Mentions feed from Gnip cannot display the underlying Tweets that are returned by that feed? This would seem to severely limit the value and utility of such analytics to many businesses (who might want to reply to many of those messages, might want to follow people on Twitter discussing their company/brand/industry/competitors, and in almost all cases will want to view the full Tweet w/rich metadata not just a summarization of #s of tweets etc.) And/or would a business focused Twitter client - CoTweet, Hootsuite, Tweetdeck etc be able to offer (perhaps as part of a professional version) such enhanced Mentions feeds and display them within that application? thanks, Shannon (I'm not an active developer at the moment but I am consulting some business clients on a range of social media tools and as analytics and the appropriate use of them is a core part of my recommendations I'm following these developments closely and look forward to I hope new competitors in the analytics space soon) - Real Things - http://realthings.posterous.com/ Slow Brand - http://slowbrand.com Searching for the Moon - http://shannonclark.wordpress.com - cell: 1.510.333.0295 Twitter - rycaut On Wed, Nov 17, 2010 at 10:09 AM, Ryan Sarver rsar...@twitter.com wrote: Dewald, The basic levels of all of the streaming APIs -- Spritzer, Follow, Track -- will remain open, free and direct from us. Elevated levels for non-display use will be served through Gnip. Hope that answers the question. Best, Ryan On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius dpr...@gmail.com wrote: Ryan, The Gnip blog post states: [QUOTE]Twitter Decahose. This volume-based product is comprised of 10% of the full firehose. Starting today, developers who want to access this sample rate will access it via Gnip instead of Twitter. Twitter will also begin to transition non-display developers with existing Twitter Gardenhose access over to Gnip.[/QUOTE] How does this affect the basic statuses/sample method of the Streaming API? Are you discontinuing it? If so, when? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com
Re: [twitter-dev] Re: Twitter + Gnip Partnership
That's explicitly not true. You are bound by both the Twitter API Rules and Gnip's TOS On Wed, Nov 17, 2010 at 1:31 PM, Dewald Pretorius dpr...@gmail.com wrote: By the way, if you get Twitter data from Gnip, you are not bound to the Twitter TOS. Your business and contractual relationship is with Gnip, not Twitter. On Nov 17, 3:28 pm, Dewald Pretorius dpr...@gmail.com wrote: The minimum Gnip charge is $500 per month, with a minimum of a year contract, if you want to use Gnip in a production application. And that's before the -- still unknown -- additional access charges for the Twitter feeds. You can't use Gnip in a production application if you are not an incorporated business, so that excludes access for many developers, even if they can afford the charges. Maybe there's a secondary market here, for an incorporated business to provide access for one-man developers to Gnip data for a fee. Meaning, Reseller Inc subscribes to Gnip and gets the data feeds, and resells them to one-man developers. I haven't checked Gnip's TOS to see if that's expressly prohibited. On Nov 17, 2:51 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Ryan, what about User Streams? I'm building something around User Streams but it is a non-display analytics application. Am I at risk for Twitter inserting another business into *my* data stream as well? And I'm curious how some of the other Streaming consumers are going to react to insertion of a monopoly middleman into their data source. I briefly dealt with Gnip a while back and found their API hard to use and their pricing exorbitant. -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: Twitter + Gnip Partnership
Ed, many developers don't want or can't afford the full Firehose. The market for Gnip is very large based on the demand that we were unable to serve. On Wed, Nov 17, 2010 at 2:04 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: I quite frankly don't see *any* economic value in a downsampled Firehose. Why should *anyone* pay Gnip for 10% or 50% of the Firehose when they can negotiated *directly* with Twitter for the whole Firehose? -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos Quoting Dewald Pretorius dpr...@gmail.com: The minimum Gnip charge is $500 per month, with a minimum of a year contract, if you want to use Gnip in a production application. And that's before the -- still unknown -- additional access charges for the Twitter feeds. You can't use Gnip in a production application if you are not an incorporated business, so that excludes access for many developers, even if they can afford the charges. Maybe there's a secondary market here, for an incorporated business to provide access for one-man developers to Gnip data for a fee. Meaning, Reseller Inc subscribes to Gnip and gets the data feeds, and resells them to one-man developers. I haven't checked Gnip's TOS to see if that's expressly prohibited. On Nov 17, 2:51 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Ryan, what about User Streams? I'm building something around User Streams but it is a non-display analytics application. Am I at risk for Twitter inserting another business into *my* data stream as well? And I'm curious how some of the other Streaming consumers are going to react to insertion of a monopoly middleman into their data source. I briefly dealt with Gnip a while back and found their API hard to use and their pricing exorbitant. -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Hat’s off to you and your collea gues
Dave, we really appreciate your note and the kind words. We appreciate all the time that you guys as developers devote to working on our API, providing feedback and being an active part of the community. It's great to know that Taylor, Matt and the rest of the team's hard work pays off sometimes :) As always, please let us know how we can continue to be better -- both in code and support. Thanks again, Ryan On Fri, Nov 12, 2010 at 4:01 AM, Dave-twiends i...@davesumter.com wrote: To the twitter team, I just wanted to drop you guys a quick note to say, great job..! I follow these groups and it seems that you guys don’t get enough thank you’s, so thank you..! I’ve been using the API for over a year now and I can’t tell you how impressed I am with it. You’ve steadily improved the reliability and uptime of it, while still adding new functionality. And I know you have to do this for a system that must have to scale well over 100bn records now. I’ve recently been doing some integration work with another large social networking site, and I can tell you it’s a nightmare. That made me realized that I’ve been taking for granted what you guys have achieved with this api. Well done guys Hat’s off to you and your colleagues. Dave Twiends -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Temporary changes to whitelisting
I wanted to email everyone and give notice that we are going to be holding off on approving any additional whitelist requests until after the World Cup is over. We actually paused this last week, so if you haven't gotten a response, this is why. It will take us a while to get through the backlog after the World Cup, so please be patient and don't reapply as it just makes it more difficult to suss through the requests. Please let me know if you have any questions. Best, Ryan
Re: [twitter-dev] Keep it real
Abraham, Really sorry to hear that we'll be losing you. You have been a HUGE part of this community for many years and have helped countless developers make their way through, at times, really choppy waters. We can't thank you enough for the time and energy you have put into helping developers in the twitter API community grow and please know we are really appreciative of all your efforts. FWIW, we are all in agreement that the mailing list is probably no longer the right tool for the community and are actively looking at other solutions. Any suggestions are welcome. If you ever need a reference, please consider us top of the list :) Best wishes and hopefully we'll find you lurking. Ryan On Mon, Jun 14, 2010 at 9:13 PM, Abraham Williams 4bra...@gmail.com wrote: I just wanted to let everyone know that I won't be on the list much going forward. Reading the list has become a time consuming burden (1000+ emails/month) and much of it has become reiteration for me. Getting more time on my own projects and paying for the roof over my head are top priorities right now. But if you have questions pertaining to me feel free to cc me on them and I will be more then happy to jump in. If you are interested in hiring me for Twitter integration projects (especially OAuth with just over 2 weeks left) or just want to say hi you can reach me as 4bra...@gmail.com or @abraham. Oh. I have several Twitter API related blog posts in draft so be sure to look for them on http://blog.abrah.am/. I'll be around :) Abraham - Abraham Williams | Hacker Advocate | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private.
Re: [twitter-dev] Annotations Hackfest Update - join in remotely!
Ed, I'm going to post a wiki page shortly to coordinate all the local and remote groups. Stay tuned, it kicks off at 1pm PST today On Sat, May 29, 2010 at 11:03 AM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ryan Sarver rsar...@twitter.com: Hey all, Just wanted to update everyone and let you know that we are going to be extending the Annotations hackfest to anyone interested, regardless of whether or not you are able to make it to SF. We'll be providing a preview of Annotations to anyone interested with the caveat that it might get torn down again after the weekend is over if we feel like we need to make some changes based on the feedback from the weekend. Unfortunately the actual judging will only be possible for people that are able to make it to the office, but we wanted to make sure developers around the world were able to participate and provide feedback on this EARLY preview of Annotations. Your hard work will still get featured with everyone else's in the blog or wherever we end up putting links to all that was accomplished over the weekend. We will also be trying to setup video uplinks so we can all get to meet each other virtually, regardless of where you are geographically. So get your webcams ready. You'll still need to submit through the form in the blog post ( http://engineering.twitter.com/2010/05/annotations-hackfest.html) as we need the twitter handles of people on your team so we can enable Annotations for you. Please be sure to note in the description that you will be a remote team and where you will be tuning in from. We are incredibly excited to see what everyone comes up with. See you there physically or virtually. Best, Ryan How are we coordinating the remote folks? Twitter? IRC? Email?
[twitter-dev] Annotations Hackfest wiki page
Here is the page that we'll use to coordinate everything this weekend. Let us know if you have any questions. https://apiwiki.twitter.com/Annotations-Hackfest-May-25th Best, rs
[twitter-dev] Annotations Hackfest Update - join in remotely!
Hey all, Just wanted to update everyone and let you know that we are going to be extending the Annotations hackfest to anyone interested, regardless of whether or not you are able to make it to SF. We'll be providing a preview of Annotations to anyone interested with the caveat that it might get torn down again after the weekend is over if we feel like we need to make some changes based on the feedback from the weekend. Unfortunately the actual judging will only be possible for people that are able to make it to the office, but we wanted to make sure developers around the world were able to participate and provide feedback on this EARLY preview of Annotations. Your hard work will still get featured with everyone else's in the blog or wherever we end up putting links to all that was accomplished over the weekend. We will also be trying to setup video uplinks so we can all get to meet each other virtually, regardless of where you are geographically. So get your webcams ready. You'll still need to submit through the form in the blog post ( http://engineering.twitter.com/2010/05/annotations-hackfest.html) as we need the twitter handles of people on your team so we can enable Annotations for you. Please be sure to note in the description that you will be a remote team and where you will be tuning in from. We are incredibly excited to see what everyone comes up with. See you there physically or virtually. Best, Ryan
[twitter-dev] Twitter Platform blog post
Wanted to make sure everyone saw this post from Dick. Please let us know what questions you have. The actual Terms will be posted shortly. http://blog.twitter.com/2010/05/twitter-platform.html Best, Ryan
Re: [twitter-dev] Re: Twitter Platform blog post
Adam, Thanks for the email and happy to try to clear things up. 1. The TOS go into affect today and section *4. Updates* states that everyone has 30 days to comply with any changes to the ToS. If you 2. The TOS **does not** restrict the content coming from a user, whether posted through an app on the user's behalf or by the user themself on twitter.com. To be even clearer, services that pay customers to post clearly disclosed paid tweets are not affected by the changes to the TOS. Let me know if that clears things up. Best, Ryan On Mon, May 24, 2010 at 10:51 AM, Adam Fortuna adamjfort...@gmail.comwrote: Hey Ryan (and everyone else), few questions about the fine details of this I'd love to get clarification on. First and foremost - when do the new TOS go into effect? I see they're already up on the API TOS page ( http://dev.twitter.com/pages/api_terms ), but would like clarification. We're suddenly in violation now, so want to see what kind of timeline we have to comply. Are you'll going to start enforcing this immediately, or do you'll have a set date to comply with the new TOS by. One of the points in the post, the killer line obviously, is we will not allow any third party to inject paid tweets into a timeline on any service that leverages the Twitter API. Based on that it seems it's still within the rules if a Twitter User posts an ad themselves to Twitter manually, rather than a 3rd party doing it? Can you verify if that's a violation or not? From the blog post it would seem that is acceptable, but the one line from the new TOS might negate it: Tweets may be used in advertisements, not as advertisements.. Does this mean that even a tweet posted manually to a users timeline cannot be an advertisement? In other words, no commerce, whether it's direct relationship between a Tweeter and an Advertiser, or through an intermediary (SponsoredTweets, Ad.ly, etc) is a violation -- whether the 3rd party posts it themselves of the Twitter User does the actual posting? Thanks, hope to get clarification soon, Adam Fortuna SponsoredTweets http://sponsoredtweets.com
Re: [twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
I want to make sure this part is clear -- this policy change isn't meant to say that we are going to start policing if the content of something a user tweets is an ad or not. The policy change affects 3rd party services that were putting ads in the middle of a timeline. So if Liz is paid by Reebok to tweet about how much she loves their new shoes, we are not going to be policing that any more than we were on Friday. This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. It *does prohibit* an application from calling out to a service to find an ad to serve to Liz that will get inserted into the timeline she is viewing. The language is somewhat nuanced but it sounds like we might need to make the policy more explicit as a number of people are misinterpreting it. Let me know if you have more questions. Ryan On Mon, May 24, 2010 at 12:26 PM, Dewald Pretorius dpr...@gmail.com wrote: Liz, You are 100% correct in summarizing the problem. Not only were those businesses built with the full knowledge of Twitter, Twitter even had specific rules governing sponsored tweets (had to be clearly marked as sponsored, etc.). I'm really baffled by this decision of Twitter, because I don't understand how they expect to have integrity and trust with developers while doing this type of stuff. Right now we are all being pointed to Annotations as the holy grail of new development. But how do we know that they won't yet again change a rule in the future that will kill businesses that were built on top of Annotations? On May 24, 3:56 pm, Liz nwjersey...@gmail.com wrote: Peter, I think the problem is that business have been created, received funding and developed over the past year, with the full knowledge of Twitter, and this just undercuts destroys them. I think people can understand the rationale (and the desire for Twitter to eliminate competition) but this is a policy decision that should have been made over a year ago. Twitter should have included this in an earlier terms of service instead of giving an implicit okay to services like Sponsored Tweets which has turned into a successful company. It also seems disingenuous that the blog post says that a guiding principle of Twitter is that We don't seek to control what users tweet. And users own their own tweets. and allow adult-oriented content and photos but for some reason, users can't Tweet ads. That sounds like control of content to me. Liz
Re: [twitter-dev] Slow response to twitter updates for a third party app
Thanks for the notice. That is definitely not an expected behavior or response time. We're investigating the cause and will follow up with more information as we figure out the cause. Thanks for reporting it. Best, rs On Saturday, May 8, 2010, Naveen Ayyagari nav...@getsocialscope.com wrote: We see the same huge latency and timeouts as well (our timeouts are also at 30 seconds). We running out of a US data center on multiple machines, we see this issue on all if our servers. I agree with @tjaap, would like to hear twitters reaction as well. On May 7, 6:02 pm, Tjaap jdmeij...@gmail.com wrote: I'm seeing exactly the same: big latency and a lot of timeouts. When posting a tweet, Twitter sometimes does not return a response within 30 seconds. After my curl times out, the app has no way of knowing if the post made it or not. Sometimes it will appear on Twitter and sometimes it won't. This effectively breaks our app. Replicated the error on two different servers (in the Netherlands) and with different accounts. I would very much appreciate a reaction from Twitter on this. We are in the process of switching to OAuth, but I would like to know if I have to implement a workaround while we're on the old system. Thanks, @tjaap
Re: [twitter-dev] Re: Slow response to twitter updates for a third party app
Raj, Naveen, @tjaap, Do any of you still have tcp dumps of the calls you were making that were getting long timeouts? On Sat, May 8, 2010 at 12:08 AM, Naveen Ayyagari nav...@getsocialscope.comwrote: We see the same huge latency and timeouts as well (our timeouts are also at 30 seconds). We running out of a US data center on multiple machines, we see this issue on all if our servers. I agree with @tjaap, would like to hear twitters reaction as well. On May 7, 6:02 pm, Tjaap jdmeij...@gmail.com wrote: I'm seeing exactly the same: big latency and a lot of timeouts. When posting a tweet, Twitter sometimes does not return a response within 30 seconds. After my curl times out, the app has no way of knowing if the post made it or not. Sometimes it will appear on Twitter and sometimes it won't. This effectively breaks our app. Replicated the error on two different servers (in the Netherlands) and with different accounts. I would very much appreciate a reaction from Twitter on this. We are in the process of switching to OAuth, but I would like to know if I have to implement a workaround while we're on the old system. Thanks, @tjaap
Re: [twitter-dev] RE: FW Twitter Support
I just wanted to jump into the thread and make sure to clarify a few things being discussed. 1) Re MyPostButler specifically - Brian and the Policy team did the right thing in responding to Dean and notifying him that his app is currently in violation of a number of policies that are listed in the Twitter Rules ( http://help.twitter.com/forums/26257/entries/18311) including: - Auto-follow by Keyword - Bulk unfollowing - Promoting serial account creation for the purpose of auto-following Brian and the team then offered to work with him to fix his app to be within the guidelines before switching over to OAuth to ensure his app wouldn't be suspended. We have to work together to protect the integrity of the ecosystem and all of the rules are in place for everyone's benefit. While bulk unfollow is a somewhat ambiguous rule, the real signal is if users of your application end up getting suspended frequently. We will work with applications to address the functionality until it no longer happens. If the app is unable or unwilling to make changes, the application will be suspended. It's also important to note that if your app incentivizes spammy behavior, like allowing them to switch app tokens for the sake of creating vanity URLs or hiding the source of the application ( http://blog.collins.net.pr/2010/04/oh-snap-mypostbutler-20-is-back.html), those users will be suspended and eventually banned. We would all much rather be spending our time helping improve the ecosystem instead of policing bad behavior. 2) @mypostbutler was suspended due to a clear violation of the Twitter Rules that prevents any user from selling their Twitter username. 3) Suspension emails don't currently include the exact reasons that an app is being suspended. We do call out the Twitter Rules and the ability to contact a...@twitter.com to get a definitive answer as to why it was suspended. Brian and the team will always provide explicit answers as to why a particular app was suspended. This is something we want to fix in the tools we use and I will make sure we do so in order to provide more clarity up front. In the end, we do not tolerate spammy behavior from users or from apps that enable it. Most everyone in the ecosystem builds app that add great net value and we would much rather be spending our time helping them then having to police bad behavior. I am happy to answer any policy questions or provide more context around how we make the decisions we make. We are also always looking to improve the process around how we interact and communicate with developers (like suspension notices including exact reasons for suspension) so please let us know any constructive ways that we can improve that and provide more clarity and certainty to you. Ryan On Mon, Apr 26, 2010 at 1:57 PM, John Meyer john.l.me...@gmail.com wrote: On 4/26/2010 1:37 PM, Dean Collins wrote: John, Nope, Dossy is pretty much on the money, I don't care about the money and I'd prefer to see people using it rather than let it die. Basically I'm a little over twitter and their amateur approaches to certain things. I'd be the first person lining up to pay my $20 a month or whatever for real commercial accounts with real support one on one support contacts 9eg something goes wrong you call the person you dealt with alst time so as not to explain everything again).. you'll get no arguments that the support needs to be improved just a little. The fact that I'm shocked that you even got an explanation shows me just how much work needs to be done. But let's look at the site promoting your program, which I think you're promoting through http://www.mypostbutler.com/ . According to what you posted, one of the reasons your app got denied because of bulk unfollowing. Well, on your site you use the words Bulk unfollow users. You may have explained it in your message, but you did not add an explanation to the fact that you have to manually check their names in order to undelete. And then there's your first paragraph: Do You understand the difference between a web based Twitter tool that can make 150 API calls an hour for a single Twitter account and a dedicated Twitter .Net application running directly on your computer that can make 20,000 API calls an hour across multiple accounts? Ignoring the fact that this paragraphs hits people over the head with the difference between 150 and 2 (aka a beigelist and a whitelist), it dosen't make sense. Why woulddn't a web site built upon twitter not whitelist their own ip address particularly if they have multiple twitter accounts? And you also mentioned MLM schemes closeby, if only in the negative. Who exactly is buying your product that you need to mention that? Maybe this will do nothing, but I'd frame that into a legal (according to twitter's rules) use. For instance, you might mention families who have multiple twitterers but only one IP address. Kinda frustrating to get on a
Re: [twitter-dev] Is there small size follow button?
Tim, We're going to work on a smaller one soon. We wanted to make sure the username of the person you are following was included so that you knew exactly who you were following when you clicked the button. Also, we created a new devlist for @Anywhere specific stuff. Check it out: http://groups.google.com/group/twitter-dev-anywhere Stay tuned. On Fri, Apr 30, 2010 at 1:23 AM, Tim Haines tmhai...@gmail.com wrote: I'd consider using this if there was a small one available too. On Fri, Apr 30, 2010 at 12:12 PM, paloalto sungh...@gmail.com wrote: Follow button in @anywhere api is too large. Is there a way to choose a smaller size?
Re: [twitter-dev] Re: Chirp is coming to San Francisco April 14 and 15
Mo, as Taylor said, just grab a Hack Day ticket and we'll see you there! On Tue, Apr 13, 2010 at 9:06 AM, Mo maur...@moluv.com wrote: The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comand register. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] What's happening with Tweetie for Mac
One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan
[twitter-dev] Some thoughts leading up to Chirp
I wanted to email everyone and share my thoughts on the acquisition from Friday, the communication around it and where we are going from here. We're incredibly excited about Chirp, and I think an open dialogue going into it is important. I look forward to meeting many of you there and continuing the discussion. We love the Twitter ecosystem and work hard every day to help support you and make the platform you are building on as successful as it can be for everyone involved. We love the variety that developers have built around the Twitter experience and it's a big part of the success we've seen. However when we dug in a little bit we realized that it was causing massive confusion among user's who had an iPhone and were looking to use Twitter for the first time. They would head to the App Store, search for Twitter and would see results that included a lot of apps that had nothing to do with Twitter and a few that did, but a new user wouldn't find what they were looking for and give up. That is a lost user for all of us. This means that we were missing out an opportunity to grow the userbase which is beneficial for the health of the entire ecosystem. Focus on growing and serving the userbase is beneficial to everyone in the ecosystem and more opportunities become available with a larger audience. We believe strongly that the ecosystem is critical to our success and this move doesn't change that. We have analytics that show our most engaged users are ones that use SMS, twitter.com AND a 3rd-party application. It further proves that there are different audiences and needs that we can never meet on our own and we all need to work together to provide what is best for the users. Once I understood the long-term view I strongly believed it was not only the right thing to do for users, but the right thing to do for the ecosystem as a whole. To be clear, we are going to work hard to improve our product, add new functionality, make acquisitions when it's in the best interest of users and the whole ecosystem at large. Each one of those things has the potential to upset a company or developer that may have been building in that space and they then have to look for new ways to create value for users. My promise is that we will be consistent in always focusing on what's best for the user and the ecosystem as a whole and we will be sincere and honest in our communication with you. To the point that we can, we will try to give more certainty about the areas where we think we can maximize benefit to users. We will continue to focus on what is best for users and we will work together to make sure that we are creating more opportunities for the ecosystem on the whole. We will also admit our mistakes when they are made and the Blackberry client should never have been labeled official. It has since been changed and you won't see that language used with Twitter clients in the future. This week will hopefully show that we are focused on building a platform that no longer just mirrors twitter.com functionality, but offers you raw utility that provides much greater opportunities to innovate and build durable, valuable businesses. I also want this week to be an opportunity for us to get together and discuss the future of the platform and how we can improve our communication, responsiveness and clarity. We have an open office hours at 10:15am on Thursday at the Hack Day and I invite all of you to come by for a discussion to talk about the future of the platform and help us craft a working relationship that is beneficial for both of us. I will provide a free ticket to anyone from this list that is unable to afford the current price so that they can be part of that discussion. Just email me directly. For those of you who can't make it to Chirp, it will be live streamed so you can tune in from home -- where ever home might be. As always, you can reach me by email or by phone, 617 763 9904. I am here to listen and provide clarity when possible and you should know we are committed to working with you on this. Best, Ryan -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Final Hack Day schedule for Chirp with discount code
Hey all, Wanted to let you know that we have finalized the schedule for Hack Day sessions at Chirp. We're really excited about the content and would love to have you there. Also, each session has a Google Moderator section setup so you can get your questions in ahead of time. Be sure to add your questions so the speakers know what to talk to: http://bit.ly/dbpnXZ Hack Day tickets are still available and we're providing a 50% discount for the first 100 registrations from the mailing list. Please don't share this outside of this list http://chirp.eventbrite.com/?discount=DEVTALK10 Hopefully see you next week! Best, rs *Quick Agenda for Hack Day* *Apr 14th* - 6pm - Hack Day registration, dinner and drinks - 8pm - Ignite Chirp hosted by Brady Forrest - 9pm+ - Hacking for the night owls *Apr 15th* - 8am - 10am - Registration and breakfast (Registration is open all day) - 10am - Welcome with Ron Conway - 10:15am - 5pm - Sessions start and go all day with a lunch you shouldn't miss - 5pm - App Showcase with Marissa Mayer, Paul Graham and Philip Kaplan. Moderated by Jason Goldman (@goldman) - 9pm - Chirp Party at 1015 Folsom *Hack Day Sessions* *Twitter Streaming API Architecture and What's Next* #chirpstream with John Kalucki *Eating our own Dogfood: Designing Twitter Mobile Web* #chirpmobile with Leland Rechis *We Have Faith In (Most of) You: How Twitter Crafts Policies to Allow Good Apps to Thrive* #chirppolicy with Del Harvey *Office Hours: Twitter Platform Team* with Ryan Sarver, Doug Williams, Raffi Krikorian, Mark McBride, Dana Contreras, Isaac Hepworth, Marcel Molina, Taylor Singletary, Todd Kloots, Wilhelm Bierbaum *Office Hours: Design/UX *with Doug Bowman, Zhanna Shamis, Britt Selvitelle, Patrck Ewing, Mark Trammel, Vitor Lourenço, Mark Otto, Coleen Baik *Integrating @anywhere* #chirpanywhere with Todd Kloots, Dustin Diaz, Dan Webb, Russ D'Sa *Effective Use of the Twitter Search API *#chirpsearch with Eric Jensen *Analyzing Big Data at Twitter* #chirpdata with Kevin Weil *Office Hours: Working at Twitter* @jointheflock with Oliver Ryan, Bernadette Coh, Jamie Narva, Michelle Gale, Morgan Missentzis, Olivia Watkins *Office Hours: The Electronic Frontier Foundation* with Marcia Hofmann, Kurt Opsahl, Cindy Cohn, Fred von Lohmann *Twitter, Media, and Kanye's Exploding Head* #chirpmedia with Chloe Sladden, Robin Sloan *Too many secrets, but never enough: Twitter OAuth *#chirpoauth with Taylor Singletary, Raffi Krikorian *Changing Engines Mid-flight: Moving Twitter from MySQL to Cassandra*#chirpcassandra with Ryan King *Birds of a Feather: Real-Time Search* with Doug Cook *Office Hours: Trademark Policy and Branding Guidelines *with Jillian West, Jeremy Kessel, Francesca Helena, Tim Yip, Bakari Brock *The How and Why of Scala at Twitter* #chirpscala with Alex Payne *What's happening? to What's happening here?* #chirpgeo with Raffi Krikorian *Thinking in Streams: Patterns for Stream Processing* #chirpstream with John Kalucki *Meet and Greet: Founders* with Evan Williams and Biz Stone *Office Hours: Twitter Corp and Business Development* with Elizabeth Weil, Doug Williams, Isaac Hepworth, Bakari Brock, Jessica Verrilli *Billions of Hits: Scaling Twitter* #chirpscale with John Adams *Twitter International* #chirpintl with Matt Sanford *All Aboard? Turning Users into Active Users* #chirponboard with Josh Elman *Meet and Greet: Funding* with David Cohen, Paul Graham, Ron Conway *Birds of a Feather: Media Curation* with Chloe Sladden and Robin Sloan -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Cancelled deprecation of /statuses/public_timeline
I wanted to send an update that based on everyone's feedback we have come up with a solution that will allow us to keep /statuses/public_timeline alive and we will no longer be deprecating it. Thanks for jumping into the thread and giving us all of the great feedback. It helped us prioritize this and come up with a solution that would work for everyone. Let me know if you have any questions. Best, Ryan
[twitter-dev] Deprecating /statuses/public_timeline resource on 4/5/10
This is an announcement that we will be deprecating the * /statuses/public_timeline* resource as of April 5th (4/5/10). Please let us know if there are any major concerns. Thanks, Ryan
[twitter-dev] @twitterapi meetup @ Twitter HQ
Hey folks, We wanted to let you know that we're hosting a little developer gathering at our new offices this coming Monday afternoon. The meetup is meant to be an informal gathering of Twitter developers where we will be available to hear how we can improve and answer any questions you have. We'll give a quick state of the union of the platform and then open up for questions from both the audience and from people online. We want you all to build things that push us in ways we haven't been thinking about and we'd love to learn how we can provide a platform that helps you innovate. We'll be providing developer staples, like beer and pizza, and we'll leave a bunch of time at the end for everyone to mingle, meet each other and meet the whole @twitterapi team. We look forward to doing more events like this regularly in the future and look to improve them based on your feedback. *** Please note, while we would love to have everyone join us, space is limited to around 150 so you'll need to register on http://twitterapi-meetup.eventbrite.com and you'll need a confirmed ticket to get into the building. We look forward to hosting you here. Ryan
Re: [twitter-dev] Re: @twitterapi meetup @ Twitter HQ
We won't be having a live video stream of the event this time around. We will be in the IRC channel and we'll be using Google Moderator to take questions from people both at the event and people who are remote. We'll walk before we run :) On Fri, Feb 26, 2010 at 12:42 PM, M. Edward (Ed) Borasky zzn...@gmail.com wrote: On Feb 26, 12:33 pm, Abraham Williams 4bra...@gmail.com wrote: A live feed would be awesome. Also the event says March 1st through April 1st... Ah ... an early April Fools' joke? ;-) I'm waiting for Linus Torvalds' April Fool email - I'm guessing this year he'll announce that he is buying Twitter ;-) But I'd settle for an IRC channel today and a Live from Twitter HQ broadcast in full streaming fashion at a later date ;-)
Re: [twitter-dev] huge Fail Whale quotient suddenly
Tim, We are working on this for our forthcoming developer site. Mark should be posting to the list in the coming days to get feedback from everyone on what they would like to see. We know it's needed and look forward to finally having something in place. Best, Ryan On Wed, Feb 17, 2010 at 6:54 AM, Tim Haines tmhai...@gmail.com wrote: Hey Raffi, It would probably be helpful for a lot of us if the status blog (or another secondary indicator) was more accurate in terms of being a problem/no problem indicator. Even if it didn't have an indication as to cause or expected time to resolve, just a little flag that said 'we acknowledge an increased error rate right now' it would be helpful. Tim. On Wed, Feb 17, 2010 at 7:27 PM, Raffi Krikorian ra...@twitter.com wrote: yeah - by the time we got ready to put the post up, on this particular issue, we had solved the problem. On Tue, Feb 16, 2010 at 6:30 PM, Abraham Williams 4bra...@gmail.com wrote: Never did get a post on status.twitter.com on this. Abraham On Mon, Feb 15, 2010 at 15:24, Raffi Krikorian ra...@twitter.com wrote: we're aware of the issue and are working on it - i expect a post to status.twitter.com in a bit. On Mon, Feb 15, 2010 at 3:17 PM, Yu-Shan Fung ambivale...@gmail.com wrote: We're seeing the same thing, especially with OAuth. Nothing's posted on status.twitter.com yet. Any updates? Thanks! Yu-Shan On Mon, Feb 15, 2010 at 2:50 PM, Cameron Kaiser spec...@floodgap.com wrote: Over the last few minutes, I'm seeing a huge jump in Fail Whales. What happened? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Everyone is entitled to my opinion. -- James Carpenter - -- “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 -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Application Suspended
Sorry I am a little late to the thread and there are a lot of topics here so I'll do my best to cover them. 1. Email notices - we send out an email for warnings and for suspensions every time to the email on record for the account that is being suspended. If the email isn't up to date or isn't valid then you won't receive it, but otherwise an email goes out every time. So it would be good to make sure the email on record for each account is a valid one. 2. Dispute a warning or suspension - we've always said that emailing a...@twitter.com is the right path for disputing a warning or suspension. If you feel that you have emailed us at that address and haven't gotten a response, let me know, but the whole reason we use ticketing on that email endpoint is to make sure we follow up with each thread. 3. Publication of policies - we are working to make them clearer and easier to find. However, we disagree that posting explicit boundaries is a good idea. The policies are in place to help enforce the spirit of Twitter which cannot be broken down into explicit numbers. If you are having problems with living on the edges of the unpublished numbers, then you are likely doing something that is not within the spirit of the platform. 4. Hostile language - we have said over and over that we are open to constructive criticism. It forces us to be better and we strive to be better, however, we won't put up with hostile and inflammatory language on the list. We're all professionals here and we expect a certain level of professionalism from everyone on the list. Let me know if you have any questions. Best, Ryan On Tue, Feb 16, 2010 at 8:59 AM, Dewald Pretorius dpr...@gmail.com wrote: Nom nom nom, say the spammers. Add to that method a few proxies and/or IP addresses, or something as simple as giving your users a PHP proxy pass-thru script that they can upload to their servers, and there is no way that Twitter can even identify the offending app, let alone suspend/ban/blackhole it. On Feb 16, 12:28 pm, PJB pjbmancun...@gmail.com wrote: Presumably to do the OAuth vanity plate, you have to do what you described in your disgruntled developer post above. I.e., the user registers their own OAuth app and enters the corresponding values in your app, allowing you to masquerade as their app in tweets. Frankly, it seems to run counter to the purposes of OAuth. But the developer of one vanity plate app I found publishes email correspondence with Brian from Twitter, and says they have been personally vetted by Twitter, so I guess it is okay...
Re: [twitter-dev] Cannot view my OAuth client's details - over capacity messages
Mike, It's a known issue right now (sorry) but I don't know when a fix is going out for it. Best, Ryan On Tue, Feb 16, 2010 at 8:03 AM, Mike Champion mike.champ...@gmail.comwrote: Over the past several weeks, I have never been able to view the details of 1 of my OAuth clients, when I go to: http://twitter.com/oauth_clients/details/XX I can view the details of my other apps, but this one has *consistently* given Over Capacity messages. I went to twitter.com/ help and didn't see any other issues filed, and even though I was logged in to ZenDesk, didn't see a way to open a support request. I'm posting here because I'm stumped at how to fix this, and it is for our company's main app so I'd really like to be get this resolved. Has anyone seen this? Any clues on what I can do? Thanks, -mike
Re: [twitter-dev] Re: Application Suspended
Jim, It's part of the functionality of the tool, so it's not something that is prone to a human forgetting. Is the jim_fulford account the one that your OAuth tokens are associated with? Either way, a...@twitter.com is your best channel for follow up. Thanks, Ryan On Tue, Feb 16, 2010 at 2:06 PM, Jim Fulford j...@fulford.me wrote: Ryan, can you check and see if #1 below is really happening. My twitter account is jim_fulford. It has my main email on it, and has never been changed. I did not get a warning or a suspension notice of any kind. Thanks Jim Fulford On Feb 16, 1:46 pm, Ryan Sarver rsar...@twitter.com wrote: Sorry I am a little late to the thread and there are a lot of topics here so I'll do my best to cover them. 1. Email notices - we send out an email for warnings and for suspensions every time to the email on record for the account that is being suspended. If the email isn't up to date or isn't valid then you won't receive it, but otherwise an email goes out every time. So it would be good to make sure the email on record for each account is a valid one. 2. Dispute a warning or suspension - we've always said that emailing a...@twitter.com is the right path for disputing a warning or suspension. If you feel that you have emailed us at that address and haven't gotten a response, let me know, but the whole reason we use ticketing on that email endpoint is to make sure we follow up with each thread. 3. Publication of policies - we are working to make them clearer and easier to find. However, we disagree that posting explicit boundaries is a good idea. The policies are in place to help enforce the spirit of Twitter which cannot be broken down into explicit numbers. If you are having problems with living on the edges of the unpublished numbers, then you are likely doing something that is not within the spirit of the platform. 4. Hostile language - we have said over and over that we are open to constructive criticism. It forces us to be better and we strive to be better, however, we won't put up with hostile and inflammatory language on the list. We're all professionals here and we expect a certain level of professionalism from everyone on the list. Let me know if you have any questions. Best, Ryan On Tue, Feb 16, 2010 at 8:59 AM, Dewald Pretorius dpr...@gmail.com wrote: Nom nom nom, say the spammers. Add to that method a few proxies and/or IP addresses, or something as simple as giving your users a PHP proxy pass-thru script that they can upload to their servers, and there is no way that Twitter can even identify the offending app, let alone suspend/ban/blackhole it. On Feb 16, 12:28 pm, PJB pjbmancun...@gmail.com wrote: Presumably to do the OAuth vanity plate, you have to do what you described in your disgruntled developer post above. I.e., the user registers their own OAuth app and enters the corresponding values in your app, allowing you to masquerade as their app in tweets. Frankly, it seems to run counter to the purposes of OAuth. But the developer of one vanity plate app I found publishes email correspondence with Brian from Twitter, and says they have been personally vetted by Twitter, so I guess it is okay...- Hide quoted text - - Show quoted text -
Re: [twitter-dev] Re: question regarding API FAQ: reclaim inactive username
Aral, I'm not sure where you get the idea that we don't care about developers and that humans aren't involved in the process. Raffi and the rest of the platform team actively respond to emails from developers at all hours of the day on both weekdays and weekends. As for the issue of handing over @usernames we need to have a rational and scalable approach to doing so. We can't just hand it out to one person because we like them more than another user. So if there is a dispute over a username we need to follow a standard procedure. We obviously love our developers and work really hard to support them in all the ways that we can, but there needs to be some process that works across the board. If you have a constructive suggestion on how that can be done other than just badgering the people trying to help you, then by all means work with us on it and we are totally open to coming up with a better solution. But to date, this is the best solution we have that scales to the number and complexity of the requests that we receive. I've always stated that we are open to criticism and feedback on how we can improve, but we ask that it be done constructively. Ryan On Thu, Feb 11, 2010 at 7:45 AM, Aral Balkan aralbal...@gmail.com wrote: Ah, so Twitter wants to see a *registered* trademark number? (As an aside: why do you hate your developers, Twitter?) :) The thing is, a trademark does not _have to be_ registered to be a trademark. Products get trademark protection automatically. I guess if I don't hear back, I'll have the IP law firm I use to write a letter first. Cheaper than getting a registered trademark. Of course, the best thing would be for a _human being_ at Twitter to say: hey developer dude, we love you, sure we can do that... don't mention it! :) (I just don't get this impersonal computer says NO attitude towards developers. Is this just the corporate culture at Twitter or are you guys severely short-staffed? Thinking Twitter really needs to invest in developer relations. Maybe get someone whose job it is to handle developer relations and champion the needs of developers within Twitter?) Aral On Thu, Feb 11, 2010 at 3:28 PM, anilchawla ani...@gmail.com wrote: Raffi, thank you for the response, but it is disappointing. I have to agree completely with Aral that these requests are not for personal use. Some of us have hundreds/thousands of users around the world who use our apps as a means to participate on Twitter, and it is ultimately those users who are affected. In my my case, I have had several users mistakingly mention or try to follow this inactive spam account (http://twitter.com/tweetymail) thinking that it was associated with my service. In the meantime, I am doing the best I can to communicate with these users using another account. FYI, I did not have any success opening support tickets for brandsquatting/impersonation. Originally, I was told to wait until 1/31/10 for the username to remain inactive. When I complied and opened a new request on 2/1, I was immediately denied. It seems that brand-squatting/impersonation/brand-confusion are all irrelevant... Twitter wants to see a trademark number. I am a hobby developer who provides a free service completely out-of-pocket, and now I need to spend hundreds of dollars to register a trademark just to get access to a username that nobody ever used? I see that you have also replaced the text of the FAQ entry with the more generic policy regarding trademark infringement. This is too bad, but I guess it answers my original question -- the existing entry was no longer valid. I certainly understand that Twitter can't always transfer usernames to app developers who want them, but there are certainly cases in which a username (inactive/never tweeted/created for spam) could be put to better use. A blanket policy on trademark infringement may make sense for companies and large brands, but it does nothing at all to help the small-time hobby developers who contribute so much to the Twitter ecosystem. On Feb 10, 7:34 pm, Raffi Krikorian ra...@twitter.com wrote: hi all, please refer to http://apiwiki.twitter.com/FAQ#HowcanIreclaimaninactiveTwitteraccount. .. We are unable to transfer usernames for personal use at this time. If you believe a Twitter account may be squatting on your trademark and violating Twitter's Terms of Service, please file a ticket athttp:// help.twitter.com/requests/newregarding 'Trademark/Brand squatting'. On Wed, Feb 10, 2010 at 4:05 PM, Kyle Mulka repalvigla...@yahoo.com wrote: I also have this problem and have gotten no response whatsoever from Twitter. Here's the inactive account that I'd like to have: http://twitter.com/twilk -- Kyle Mulka Founder, Congo Labs http://twilk.com On Feb 10, 6:41 pm, Anil Chawla ani...@gmail.com wrote: Thanks, glad to know I'm not alone on this. I've looked at filing a trademark but
Re: [twitter-dev] Re: question regarding API FAQ: reclaim inactive username
Aral, Thanks for the thorough follow up. First of all we definitely care and we try to show that as opposed to just saying it. The @username issue is a really sticky one for us for a number of reasons. With that being said, I'm going to meet with our team internally to review the process and see if we can come up with better answers to your questions and see if we can improve the process at all. We want to support our developers the best way we can so we're totally open to fixing the process if it's broken. Best, Ryan On Thu, Feb 11, 2010 at 1:38 PM, Aral Balkan aralbal...@gmail.com wrote: Hi Ryan, My greatest issue with all this is that you appear to have a form response. Currently, you're just not handling account transfers at all. And that's the same policy for general users (of which you have gazillions) and developers (of which you have an order of magnitude or two less). The account I am asking about has not tweeted since 2007. It is not a request asking you to favor one person over another. It is a request to favor a new Twitter application over an account that hasn't been used in three years. If a human being looked at it, the decision would be clear and would probably take 1/10th the time to execute than all these emails have taken. My suggestion: expire accounts that haven't been used in over 12 months and don't have to deal with it. If that's too harsh, at least handle *trademark* requests. My app's name _is_ a trademark even if it isn't a _registered_ trademark. Forcing me to register my trademark (can I register it in the UK, where I live, or do I have to get a US registered trademark?) just adds more financial responsibility on my shoulders. I put in a trademark request as per the link Raffi gave but I haven't heard anything back – not even an automated response saying you guys received the email. On the whole, I just feel unloved because I've put a lot of time and effort into an app that I feel will make Twitter a bit more fun and I don't feel that the request to have the Twitter account with my app's name – one that hasn't been used in three years – is an unrealistic request to make. Let's say my app is called Dodo. I'm just sad that I am going to launch with the Twitter account @dodo or even @dodoapp – because both are taken and unused - but that I'm going to launch with @dodo_app. That you guys don't see this is a problem makes me think that you don't care. All the best, Aral On Thu, Feb 11, 2010 at 8:24 PM, Ryan Sarver rsar...@twitter.com wrote: Aral, I'm not sure where you get the idea that we don't care about developers and that humans aren't involved in the process. Raffi and the rest of the platform team actively respond to emails from developers at all hours of the day on both weekdays and weekends. As for the issue of handing over @usernames we need to have a rational and scalable approach to doing so. We can't just hand it out to one person because we like them more than another user. So if there is a dispute over a username we need to follow a standard procedure. We obviously love our developers and work really hard to support them in all the ways that we can, but there needs to be some process that works across the board. If you have a constructive suggestion on how that can be done other than just badgering the people trying to help you, then by all means work with us on it and we are totally open to coming up with a better solution. But to date, this is the best solution we have that scales to the number and complexity of the requests that we receive. I've always stated that we are open to criticism and feedback on how we can improve, but we ask that it be done constructively. Ryan On Thu, Feb 11, 2010 at 7:45 AM, Aral Balkan aralbal...@gmail.comwrote: Ah, so Twitter wants to see a *registered* trademark number? (As an aside: why do you hate your developers, Twitter?) :) The thing is, a trademark does not _have to be_ registered to be a trademark. Products get trademark protection automatically. I guess if I don't hear back, I'll have the IP law firm I use to write a letter first. Cheaper than getting a registered trademark. Of course, the best thing would be for a _human being_ at Twitter to say: hey developer dude, we love you, sure we can do that... don't mention it! :) (I just don't get this impersonal computer says NO attitude towards developers. Is this just the corporate culture at Twitter or are you guys severely short-staffed? Thinking Twitter really needs to invest in developer relations. Maybe get someone whose job it is to handle developer relations and champion the needs of developers within Twitter?) Aral On Thu, Feb 11, 2010 at 3:28 PM, anilchawla ani...@gmail.com wrote: Raffi, thank you for the response, but it is disappointing. I have to agree completely with Aral that these requests are not for personal use. Some of us have hundreds/thousands of users
Re: [twitter-dev] Re: A proposal for delegation in OAuth identity verification
Thanks for sending this out. I did want to send a note about having developers share consumer keys and secrets with other applications. While we don't have an explicit policy yet to block this we STRONGLY advise not to hand out your tokens to other providers for a number of reasons. Most important of all is that if your tokens get compromised and abuse is associated with those tokens, we have to revoke access for the consumer. Obviously tokens can get compromised in a number of ways, but the more services you share them with the more likely they are to get compromised which could lead to revocation of your application. Raffi has proposed a way to do delegated identity using OAuth and we are open to finding other models, but we strongly advise not promoting applications to provide you with their tokens as there are always other ways of solving that same problem. Thanks, Ryan On Thu, Feb 11, 2010 at 12:37 PM, Sean Callahan seancalla...@gmail.comwrote: That is similar to what we are doing at TweetPhoto and it is working out fine. Feel free to check out what we are doing: http://groups.google.com/group/tweetphoto/web/oauth-signin Third-party apps share with us their app's consumer key and secret. We receive the same level of access to the third-party app using our photo sharing service. When two companies work together and are partners there needs to be a level of trust. Furthermore, developers can change their consumer secret at any time so their is no real issue with this method. There are a few integrations coming out soon with this method in place. Please let us know your thoughts and if you have any questions. Sean On Feb 11, 10:05 am, Brian Smith br...@briansmith.org wrote: Raffi Krikorian wrote: The term most frequently used for “delegator” is “relying party.” What you call the service provider is most frequently called the “identity provider.” What you call the consumer is usually called the “subject.” See OpenID, InfoCard, and other similar specifications for example usage of these terms. First, what I wrote about subject was misleading: the user--not the consumer--is the subject. i hear all this - it just gets a bit complicated with because we are conflating this with our oauth situation. This doesn't really have much to do with OAuth, because you are not trying to allow delegation of credentials--that is, you are not trying to allow the consumer app to let the relying party use the consumer app's OAuth access token to read/write the user's account. perhaps its time to move to an oauth + openID hybrid system. I don't know if OpenID really solves this problem well, especially for apps that aren't webapps. The subject doesn’t want the relying party to have access to the entire response from the account/verify_credentials request as if he had given the relying party read access to his account. I am not sure if account/verify_credentials returns sensitive information (information only available to apps that have been authorized by the user) yet, but I think it is likely in the future that it will do so. It would be prudent to have delegation use a different resource designed specifically for delegation. i think this is again a general case vs a twitter case. i think in the general case, the delegator would call some endpoint that would simply verify the identity through a HTTP code (2xx for success, 4xx for failure). twitter, as a special case, sends along the user object [as] part of it? account/verify_credentials discloses information that is private. For example, the HTTP header of account_verify_credentials discloses information about how frequently the user accesses twitter (the rate limit headers). If the user hasn't previously authorized (via OAuth) the delegator (relying party) to have read access to his account, then the delegator (relying party) shouldn't be able to get this information. Also, I think you should plan ahead for the case where account/verify_credentials returns even more sensitive information. If you were going to reuse an existing resource, I'd reuse users/show.format?user_id=username instead. But, AFAICT, it's much better to create a new resource for this purpose, and pretty easy to do so. I think the following would be a better protocol: Consumer to Relying Party: Give me RP-SIGNED-TOKEN, a nonce signed with your OAuth credentials for the relying party'sidentity verification service. Relying Party to Consumer: Here is the token RP-SIGNED-TOKEN. (This is done using whatever protocol the consumer and the relying party agree to use.) Consumer to Identity Provider: Here's RP-SIGNED-TOKEN. Give me IP-SIGNED-TOKEN, which is (RP-SIGNED-TOKEN, screen_name) signed with a signature that the relying party can verify is from the identity provider. Identity
Re: [twitter-dev] OAuth Additions
Dewald, 1) good idea 2) also a good idea 3) tons :) On Tue, Feb 9, 2010 at 5:28 AM, Dewald Pretorius dpr...@gmail.com wrote: Two additions to OAuth that will be very helpful: 1) When a user removes the application from their connections, Twitter should make a callback to my system so that I can delete the account from my DB. 2) There should be a call my system can make to remove the app from the user's connections, typically in the case where the user deletes his account from my system. As an aside, how many times have you misspelled oauth as ouath in your code?
Re: [twitter-dev] Re: Seesmic Look and the Source parameter
Raffi, has walking pneumonia so we're giving him a few days slack time and we're afraid of what he would write while on meds :) On Tue, Feb 9, 2010 at 8:48 AM, Raffi Krikorian ra...@twitter.com wrote: in progress :P On Tue, Feb 9, 2010 at 12:18 AM, mynetx myne...@googlemail.com wrote: And where’s the announced post by Raffi? http://groups.google.com/group/twitter-development-talk/msg/56cd59f6d5a57db9 On Feb 8, 6:39 pm, Dewald Pretorius dpr...@gmail.com wrote: The info you're looking for is in this thread: http://groups.google.com/group/twitter-development-talk/browse_thread. .. On Feb 8, 2:45 am, mynetx myne...@googlemail.com wrote: How can Seesmic Look display its Source in the tweet metadata, when it asks for my user name and password? It would be interesting to know how Seesmic Look gets the Twitter API to return an OAuth Access Token and its secret from a user name / password API request input. Look is connecting to Twitter via the Dimebrain TweetSharp Library for C#, but as Seesmic's class is using obfuscated .NET IL code, I have not yet found out. Any insight appreciated. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Mobile OAuth fix is LIVE
Ill talk with the team and figure out if it's better to roll it back or just limit it to the known, working user agents On Fri, Feb 5, 2010 at 3:42 PM, CharlesW cwilt...@gmail.com wrote: That's an amazingly great recommendation, Michael. -- Charles On Feb 5, 9:22 am, Michael Steuer mste...@gmail.com wrote: In fact, I'd recommend that you only show the new version for devices you have actually tested against... Mobile browser support is a crap shoot and you really can't assume that something that works on one device, works on another... You need to test each and every one of them (or at least each family of devices, e.g. Series 60 4th Gen, Series 60 5th Gen, iPhone OS, Motorola V3 series, etc.) I've been in mobile development for 15 years... Let me know if you need some pointers off list... Happy to assist. On 2/5/10 8:40 AM, CharlesW cwilt...@gmail.com wrote: Ryan, Thanks for both the attempted fix and the announcement. Unfortunately, where the previous version was kind of a crapshoot for mobile users because the buttons appeared black (see my screenshot in the bug report athttp:// code.google.com/p/twitter-api/issues/detail?id=395), this new version doesn't work at all on many mobile browsers. Because this breaks mobile Twitter support completely for many (most? all?) phones using older browsers, can you please revert to the previous version, and then stage a new version somewhere else that we can help you test? -- Charles On Feb 3, 3:16 pm, Ryan Sarver rsar...@twitter.com wrote: FINALLY! An update has just gone live that fixes rendering of the OAuth screens for most mobile devices. We also fixed a few small nagging things like the default action is now allow instead of deny if you just hit go on an iPhone. I've attached two screenshots so you can see the updated screens. Please test it out with your various mobile web apps and let us know if you run into any problems or edge cases. Ryan IMG_0739.png 93KViewDownload IMG_0738.png 75KViewDownload
Re: [twitter-dev] Re: Mobile OAuth fix is LIVE
We've had to roll back the mobile OAuth update as it was consuming an abnormally large amount of resources. We'll dig in and figure out what was going on. Almost there, rs On Thu, Feb 4, 2010 at 12:24 PM, Carlos carlosju...@gmail.com wrote: Buttons not clickable on Windows Mobile; tried on both a 6.1 6.5 device. On Feb 3, 6:16 pm, Ryan Sarver rsar...@twitter.com wrote: FINALLY! An update has just gone live that fixes rendering of the OAuth screens for most mobile devices. We also fixed a few small nagging things like the default action is now allow instead of deny if you just hit go on an iPhone. I've attached two screenshots so you can see the updated screens. Please test it out with your various mobile web apps and let us know if you run into any problems or edge cases. Ryan IMG_0739.png 93KViewDownload IMG_0738.png 75KViewDownload
Re: [twitter-dev] Re: Mobile OAuth fix is LIVE
Following up on my earlier email. I jumped the gun and the rollback never actually happened :) However, we are getting some reports of the buttons not functioning in a number of browsers and are working on a fix. Best, Ryan On Thu, Feb 4, 2010 at 3:27 PM, Ryan Sarver rsar...@twitter.com wrote: We've had to roll back the mobile OAuth update as it was consuming an abnormally large amount of resources. We'll dig in and figure out what was going on. Almost there, rs On Thu, Feb 4, 2010 at 12:24 PM, Carlos carlosju...@gmail.com wrote: Buttons not clickable on Windows Mobile; tried on both a 6.1 6.5 device. On Feb 3, 6:16 pm, Ryan Sarver rsar...@twitter.com wrote: FINALLY! An update has just gone live that fixes rendering of the OAuth screens for most mobile devices. We also fixed a few small nagging things like the default action is now allow instead of deny if you just hit go on an iPhone. I've attached two screenshots so you can see the updated screens. Please test it out with your various mobile web apps and let us know if you run into any problems or edge cases. Ryan IMG_0739.png 93KViewDownload IMG_0738.png 75KViewDownload
Re: [twitter-dev] Bulk User Look Up - any progress?
Michael, It is definitely on our near-term roadmap, but we've gotten backed up on a few other things. So it is still coming, but I don't have an exact date for you. Social graph relief is neigh :) Best, Ryan On Wed, Feb 3, 2010 at 3:39 PM, Michael Steuer mste...@gmail.com wrote: Hi Raffi et al, Is there any word on when we might see a bulk user lookup API, as promised repeatedly in this group? For those of us using the social graph APIs, it’s incredibly painful to then have to fetch the full user object based on the ID one-by-one. Anyway, would just love to know if this is on the horizon or if we should all continue to dream about this... Thanks, Michael
Re: [twitter-dev] Re: Any iPhone Twitter apps with OAuth login ?
Good news. A mobile-friendly version of the OAuth page is due to be deployed next week (finally!:). We look forward to your feedback on the new screens when they are ready. Also, we currently block any custom protocol URLs from being registered as a callback to protect against XSS attacks. However, you can email a...@twitter.com to request a custom callback for iPhone apps and other mobile platforms that support it. Thanks for your endless patience on this pesky issue. Best, Ryan On Thu, Jan 21, 2010 at 2:18 PM, hunterjensen hunterjen...@gmail.com wrote: Yes please! We're submitting an iPhone app in a couple weeks and that page is the least user-friendly thing in our whole app. At this point we're considering going back to basic auth just until it gets a more mobile-friendly UI. Any chance you guys are working on this? Anything we can do to help? On Jan 20, 2:52 am, Jeff Enderwick jeff.enderw...@gmail.com wrote: and can we contrib/help? On Tue, Jan 19, 2010 at 11:07 AM, joepwro joep...@gmail.com wrote: We are also developing an iPhone app that uses Twitter's OAuth. Posting this just to add more momentum to the request that the Twitter OAuth login page should be made mobile friendly. I believe doing so would have a significant usability impact. Raffi, can you provide input is this thread if this is something Twitter is considering doing in the short term? Long term? Thanks, Joe On Jan 17, 3:12 am, jeff.enderw...@gmail.com jeff.enderw...@gmail.com wrote: Hi, we're releasing an app that has a twitter-based sharing component in a couple of weeks. Does Twitter have any interest in making a mobile friendly version of theoauthallow/deny/pin pages? Could one of us on the outside just gin it up and give it to Twitter? On Jan 12, 7:15 am, funkatron funkat...@gmail.com wrote: Just FWIW, this isn't really aniPhone-specific issue – there are a lot of rich mobile devices out there. One reason (excuse?) for not usingOAuthin Spaz on webOS is the poor functionality on mobile. I'm really reluctant to move toOAuthuntil the flow for mobile is improved. The data from heypic.me is just what I was afraid of. -- Ed Finklerhttp://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com xmpp%3afunkat...@gmail.com On Dec 6 2009, 3:08 am, Ram group...@cascadesoft.net wrote: As a followup to the mobileOAuthdiscussions from October (seehttp:// groups.google.com/group/twitter-development-talk/browse_thread...) Does anyone know of any (publicly released)iPhoneor other mobile Twitter apps that useOAuth? I'm partly curious to know/confirm whether our app is the onlyiPhone (or mobile) app that uses TwitterOAuthlogin for posting tweets, but I also want to know what you think of the UI, if you've used TwitterOAuthlogin in any publicly released mobile app. Thanks Ram
[twitter-dev] Chirp: Twitter Developer Conference
Just wanted to give everyone a heads up now that we have officially announced the dates for Chirp and made the first 200 tickets available for purchase at http://chirp.twitter.com. Chirp will be a two day event being held on April 14th and 15th and over 800 tickets will be available in total. You can follow @chirp (http://twitter.com/chirp) for announcements. Chirp is a developer-focused event and we want to make sure the room is filled with all the right people. In fact, you'll notice that you even need to use the API to be able to purchase a ticket :) We as a company are really excited about the event and investing a lot in making this something really special. We hope to have lots of you there to celebrate the accomplishments of the ecosystem and share the roadmap of the platform. The schedule is still in development and we'll be adding more detail to the Chirp site as things come together. You can expect to hear from people at Twitter, top developers, investors and users from across the ecosystem. We are interested to hear what you would like to see content-wise, so please send us any ideas/wants you have and help us shape the conference. Also, in an effort to give cash-strapped developers access to the conference, we have a pool of Scholarship Tickets. These tickets are an opportunity for individuals or companies with the means to anonymously purchase a ticket for a budding developer without the same means to attend. If you are in a position to help another developer, please consider doing so by generously giving back to the ecosystem. If you are a developer that would like to apply for a Scholarship Ticket we'll be following up with details on how to do so soon. We look forward to your thoughts and ideas on what kind of content you think would make the conference a success. If you have feedback or are looking for things like press passes, please email ch...@twitter.com. We look forward to meeting you in person. Best, Ryan
Re: [twitter-dev] Question about Twitter use in library names
Duane, I've been able to follow up with our lawyers and they confirmed that it is ok to include Twitter in the name of libraries that developers build. Sorry it took so long to follow up, but I wanted to make sure we got a strong, final answer back before responding. Best, Ryan On Fri, Dec 4, 2009 at 1:39 PM, Duane Roelands duane.roela...@gmail.comwrote: A question for the Twitter team: I'm the developer and maintainer of an open source library called TwitterVB. Can I expect a nastygram from your lawyers at some point? Or is there some way I can have the project vetted to avoid such a thing in the future?
Re: [twitter-dev] Re: Support from a...@twitter.com sucks!!!
Dewald, I appreciate that the response email was probably not helpful to you, but there are reasons that the new zendesk-based system are greatly beneficial to the community. Surely we can tailor some of the responses so they are more specific to your inquiry (and we will do that), but it's important for us moving forward to have one ticketed channel that allows us to make sure we follow up to every response at scale. Previously those emails were coming into our personal inboxes where they could slip for weeks before we noticed them which left a developer hanging in the lurch the whole time. I would also ask of you that you assume the best of people's actions instead of following up with something as unconstructive as your first response. We are here working with you to continue to improve the system and a simple email calling out that the form response hadn't been helpful to you with a suggested email of what would have been more helpful is something we can work with you on. We are committed to building the best support we can and that can only be done through feedback from everyone on what is working and what isn't. We actually aren't getting a lot of resumes for the Developer Advocate role, so anyone on this list is interested in helping the community or knows of someone who is, please pass them along. The upside is if they do get hired they'll be in your debt :) So again, I do appreciate and hope you continue to give us feedback on how we are doing, but I hope in the future that it is in a more constructive format than your email here. Thanks, Ryan On Tue, Jan 12, 2010 at 7:59 AM, Dewald Pretorius dpr...@gmail.com wrote: Twitter support in the past has been great. That is why it was such a shock and disappointment to get that absolutely worthless canned reply to my request. And it wasn't an automated reply from the Zendesk system. The reply was manually sent many hours later. It was clearly from someone who knows absolutely nothing about the Platform. Why is such a person even looking at and responding to tickets sent to api[at]twitter.com? On this forum, Twitter staff always tell us to send support requests, debug info, etc., to api[at]twitter.com. With all the millions in cash that Twitter has in the bank, one really does not want to hear about staff shortages. On Jan 12, 4:27 am, Tim Haines tmhai...@gmail.com wrote: Twitter's been trying to hire new support staff for quite a while now. You'll probably remember Doug's email. From what I can determine, they've had no luck finding people, because it's still the engineers answering questions in here. They're stretched. Saying something sucks and following it with !!! probably doesn't help the moral of the guys who are helping - often out of hours from what I can see. I feel the frustration too, but there's definitely more constructive things you can do about it. Why not send out a tweet, or message to your other networks saying Twitter's looking for support staff? Tim. On Tue, Jan 12, 2010 at 5:50 PM, Dewald Pretorius dpr...@gmail.com wrote: I sent very specific questions to a...@twitter.com, not knowing that it is now being automatically fed into the Zendesk Twitter helpdesk system. The answer I received back consisted of: - I suggest that you check out the API wiki for this information: http://apiwiki.twitter.com/. We also have a very active and helpful community athttp://groups.google.com/group/twitter-development-talk, where our API team interacts with developers on a regular basis. You may want to join the group to participate in conversations about topics like these. Hope that helps, Support -- Well, F-ING D-UH!! Thanks for nothing.
[twitter-dev] Platform announcements from LeWeb
Hey all, Now that the dust has settled a bit and we are in the midst of the holidays I wanted to email everyone and provide some more details on the announcements we made a few weeks ago at LeWeb. *50,000 apps* We are continually amazed by all the incredible work the ecosystem does as a whole and we proud that developers have created over 50,000 applications that allow people to experience Twitter in so many different ways. We are really looking forward to what 2010 has in store as we put more emphasis on supporting the ecosystem better and maturing as a platform. We are humbled by and appreciative all the hard work you do. Please continue to give us feedback -- both good and bad -- on how we can support you better in your efforts to build awesome apps. *Auth announcements* With the recent launches of Retweet, Lists and Geotagging we have seen applications struggle to provide the experience they want for their users within the 150 req/hr limit. We are excited to open the skies up a bit and provide some more room for developers to work within. Starting in a few weeks all OAuth requests to api.twitter.com/1/ will be able to take advantage of a 10x rate limit increase. Basic Whitelisting still exists and is unchanged. We look forward to what this means in terms of the increased richness around the user experience in Twitter apps. *Developer Site* From the beginning we have used a disparate set of tools to help support the community -- from the apiwiki, to code.google.com for issues to this mailing group. It was a great way to get started quickly with fairly robust tools, but we need a place for developers to start from and help them find the right answers to their questions and help them solve their problems. We have announced a new Developer Site that begins to consolidate these communications channels and tools into a single place while adding some new, exciting tools to help developers. There will be new reference documentation, search, API console, API status dashboard (external monitoring service) and clearer documentation of policies. We are investing heavily in this area and will continue to improve the tools and content for the ecosystem to make sure that you have everything you need to get started and for continued support. We are really interested in getting your feedback on what will create a great site, so please let us know your wishlist of things that will help you be a more informed and more efficient developer. *Chirp - Twitter Developer Conference* Personally one of the most exciting announcements is that we will be throwing the first official Twitter Developer Conference which we are calling Chirp. It will be a two day event focused on equipping developers with all the tools they need to go forth and build great things. Day One will be filled with speakers from Twitter and the ecosystem talking about a broad range of topics like our roadmap, the Streaming API, how to develop desktop applications, sentiment analysis, user research and more. At the end of Day One we will kick off a 24-hour hack event with lots of great announcements and surprises already lined up. We'll also be filling Day Two with some workshops on specific topics for developers who want to dive deep in certain areas. There are lots of great surprises in store for the event and we hope to see lots of you there. *Firehose for everyone* Finally, the announcement that has garnered the most coverage and excitement. As I stated in the session at LeWeb we are committed to providing a framework for any company big or small, rich or poor to do a deal with us to get access to the Firehose in the same way we did deals with Google and Microsoft. We want everyone to have the opportunity -- terms will vary based on a number of variables but we want a two-person startup in a garage to have the same opportunity to build great things with the full feed that someone with a billion dollar market cap does. There are still a lot of details to be fleshed out and communicated, but this a top priority for us and we look forward to what types of companies and products get built on top of this unique and rich stream. Sorry for the long-winded email, but there is lots of really exciting stuff for us to be talking about. As always, we are very interested in getting your feedback on the announcements and more generally on how we can continue to improve how we work together. As I said a few times in the session, our success is dependent on your success so please let us know what we can do to help make you successful. Happy holidays, Ryan
Re: [twitter-dev] Question about Twitter use in library names
Just wanted to follow up with everyone and let you know we are still on this and haven't forgotten about the thread. Hopefully will have an answer for you soon. Best, Ryan 2009/12/5 Ryan Sarver rsar...@twitter.com Duane, We definitely don't want to be sending any nastygrams, especially for something that helps the community. I put a note into our legal / marks department so that I can get an answer back to you and everyone else. Please bear with us as it could take a bit, but I'll get you an answer. Best, Ryan On Fri, Dec 4, 2009 at 1:39 PM, Duane Roelands duane.roela...@gmail.comwrote: A question for the Twitter team: I'm the developer and maintainer of an open source library called TwitterVB. Can I expect a nastygram from your lawyers at some point? Or is there some way I can have the project vetted to avoid such a thing in the future?
Re: [twitter-dev] Status update 11:27pm PDT
We just posted a status update to blog.twitter.com which you can find here: http://blog.twitter.com/2009/12/update-on-last-nights-dns-disruption.html Please let us know if you have any questions. Best, Ryan On Thu, Dec 17, 2009 at 11:28 PM, Ryan Sarver ryan.sar...@gmail.com wrote: Just wanted to drop an email to everyone and let you know that we are investigating the issue and will follow up with more details as we determine the cause and are able to share information. Thanks for your patience, Ryan
[twitter-dev] Status update 11:27pm PDT
Just wanted to drop an email to everyone and let you know that we are investigating the issue and will follow up with more details as we determine the cause and are able to share information. Thanks for your patience, Ryan
Re: [twitter-dev] Question about Twitter use in library names
Duane, We definitely don't want to be sending any nastygrams, especially for something that helps the community. I put a note into our legal / marks department so that I can get an answer back to you and everyone else. Please bear with us as it could take a bit, but I'll get you an answer. Best, Ryan On Fri, Dec 4, 2009 at 1:39 PM, Duane Roelands duane.roela...@gmail.comwrote: A question for the Twitter team: I'm the developer and maintainer of an open source library called TwitterVB. Can I expect a nastygram from your lawyers at some point? Or is there some way I can have the project vetted to avoid such a thing in the future?
Re: [twitter-dev] Question about licensing
Just an update from our end: I am still working with our General Counsel to get answers to the questions, but it's going to take a bit. So please bear with us but we'll get an update to you in the coming weeks after we get back from LeWeb. Thanks, Ryan On Tue, Nov 24, 2009 at 9:12 AM, DeWitt Clinton dclin...@gmail.com wrote: Hi all, I recently received a request to implement the retweet api calls in the python-twitter and java-twitter libraries, but before I proceed I was hoping for a bit of clarification around the licensing terms for the Twitter API. My layman's understanding is that without explicit terms there are relatively few rights offered by default regarding a specification. In particular, I have a few questions about copyright, trademark, and patents rights being offered to implementors of the Twitter API. My longstanding sense is that Twitter has indicated the spirit of offering the API under generally permissive usage rights, so hopefully this thread can move the discussion forward a bit and perhaps turn that spirit into something more formal. *Copyright* **Question: Under what terms may third-party library and application developers use the text and images associated with the Twitter API specification? Example use case: Third-party library developers would like to copy and/or modify the text of the Twitter API specification in the library's documentation. This is preferred over inventing new text for the documentation, the meaning of which could deviate from the canonical version in the Twitter API specification. Potential concern: Without a copyright license, implementors may not be permitted to use or reuse the Twitter API specification text in third-party library documentation. Current state: While the Twitter API specification itself doesn't mention copyright, the Twitter Terms of Service (http://twitter.com/tos) state: The Services are protected by copyright, trademark, and other laws of both the United States and foreign countries, which could reasonably be interpreted to apply to the Twitter API service as well. Possible desired outcome: The Twitter API specification is made available under a permissive and derivative works-friendly copyright license, such as the Creative Commons BY or BY-SA license. *Trademark* Question: Under what terms may third-party library and application developers use the various registered service marks of Twitter, Inc? Example use case: Third-party library authors would like to use the words twitter, tweet, retweet (all live service marks of Twitter, Inc) in their libraries. This is preferred over third-party library authors inventing new terms for API methods such as retweet. Potential concern: Without terms that specify where and how the various registered marks can be used, third-party library implementors may or may not be permitted to use terms such as twitter, tweet, retweet, etc., in their libraries. Current state: The Twitter Terms of Service (http://twitter.com/tos) appear to prohibit such use: Nothing in the Terms gives you a right to use the Twitter name or any of the Twitter trademarks, logos, domain names, and other distinctive brand features. Possible desired outcome: Twitter publishes acceptable-use guidelines for registered marks in third-party libraries and third-party applications. *Patent* Question: Under what terms may third-party library and application developers make use of current or future patent claims made by Twitter, Inc? Example use cases: A third-party developer may wish to implement an independent service that conforms to the Twitter API method signatures, or a third-party developer may wish to implement a library that implements portions of the Twitter API on the client. Potential concern: Without terms that specify how third-party developers may use patent claims (if any) made by Twitter, Inc, implementors assume the risk of potentially infringing on current or future claims made by Twitter. Current state: Twitter (to my knowledge) has made no statement regarding patent claims with respect to implementations of the Twitter API. Possible desired outcome: The Twitter API specification is made available under a patent agreement, such as the Open Web Foundation Agreement ( http://openwebfoundation.org/legal/), or a similarly permissive agreement, such as the Microsoft Open Specification Promise ( http://www.microsoft.com/Interop/osp/) or a Google-style patent license ( http://code.google.com/apis/gdata/patent-license.html). ... I realize that these are meaty (and potentially legally sensitive) questions of course, and likely ones that are not easily answered in a public forum. However, any feedback from the team would certainly be appreciated. The fact that people are even thinking about these types of questions is a good thing, both for open specification development in general, but also because it shows how
Re: [twitter-dev] Sudden OAuth failures from a specific IP address
Tim, can you provide us with your IP so we can look into it? Thanks, Ryan On Wednesday, November 25, 2009, timwhitlock tim.whitl...@publicreative.com wrote: Has anyone found their existing code suddenly getting OAuth failures? I'm getting a 401 (Failed to validate oauth signature and token) Normally I'd assume that I've been an idiot and screwed up my code - Except that the code is unchanged from yesterday when it was working perfectly. I've also had the same code in production for months with no such errors, and those sites are still operating fine. This points to a problem with my IP. Can anyone at Twitter help? Have I been blocked? It's only the OAuth call that is failing. Other non-authed requests are working ok.
Re: [twitter-dev] Question about licensing
DeWitt, Thanks for the email. These are all great questions and I want to make sure I get all the appropriate answers for you and other people on the thread so it's clear and transparent. Let me work internally to make sure we get answers to these and get back to you. The more general answer is that we are working on this as we speak, so there should be some more clarity in the near future regardless of this thread. Thanks for the interest and support. Best, Ryan On Tue, Nov 24, 2009 at 9:12 AM, DeWitt Clinton dclin...@gmail.com wrote: Hi all, I recently received a request to implement the retweet api calls in the python-twitter and java-twitter libraries, but before I proceed I was hoping for a bit of clarification around the licensing terms for the Twitter API. My layman's understanding is that without explicit terms there are relatively few rights offered by default regarding a specification. In particular, I have a few questions about copyright, trademark, and patents rights being offered to implementors of the Twitter API. My longstanding sense is that Twitter has indicated the spirit of offering the API under generally permissive usage rights, so hopefully this thread can move the discussion forward a bit and perhaps turn that spirit into something more formal. Copyright Question: Under what terms may third-party library and application developers use the text and images associated with the Twitter API specification? Example use case: Third-party library developers would like to copy and/or modify the text of the Twitter API specification in the library's documentation. This is preferred over inventing new text for the documentation, the meaning of which could deviate from the canonical version in the Twitter API specification. Potential concern: Without a copyright license, implementors may not be permitted to use or reuse the Twitter API specification text in third-party library documentation. Current state: While the Twitter API specification itself doesn't mention copyright, the Twitter Terms of Service (http://twitter.com/tos) state: The Services are protected by copyright, trademark, and other laws of both the United States and foreign countries, which could reasonably be interpreted to apply to the Twitter API service as well. Possible desired outcome: The Twitter API specification is made available under a permissive and derivative works-friendly copyright license, such as the Creative Commons BY or BY-SA license. Trademark Question: Under what terms may third-party library and application developers use the various registered service marks of Twitter, Inc? Example use case: Third-party library authors would like to use the words twitter, tweet, retweet (all live service marks of Twitter, Inc) in their libraries. This is preferred over third-party library authors inventing new terms for API methods such as retweet. Potential concern: Without terms that specify where and how the various registered marks can be used, third-party library implementors may or may not be permitted to use terms such as twitter, tweet, retweet, etc., in their libraries. Current state: The Twitter Terms of Service (http://twitter.com/tos) appear to prohibit such use: Nothing in the Terms gives you a right to use the Twitter name or any of the Twitter trademarks, logos, domain names, and other distinctive brand features. Possible desired outcome: Twitter publishes acceptable-use guidelines for registered marks in third-party libraries and third-party applications. Patent Question: Under what terms may third-party library and application developers make use of current or future patent claims made by Twitter, Inc? Example use cases: A third-party developer may wish to implement an independent service that conforms to the Twitter API method signatures, or a third-party developer may wish to implement a library that implements portions of the Twitter API on the client. Potential concern: Without terms that specify how third-party developers may use patent claims (if any) made by Twitter, Inc, implementors assume the risk of potentially infringing on current or future claims made by Twitter. Current state: Twitter (to my knowledge) has made no statement regarding patent claims with respect to implementations of the Twitter API. Possible desired outcome: The Twitter API specification is made available under a patent agreement, such as the Open Web Foundation Agreement (http://openwebfoundation.org/legal/), or a similarly permissive agreement, such as the Microsoft Open Specification Promise (http://www.microsoft.com/Interop/osp/) or a Google-style patent license (http://code.google.com/apis/gdata/patent-license.html). ... I realize that these are meaty (and potentially legally sensitive) questions of course, and likely ones that are not easily answered in a public forum. However, any feedback from the team would certainly be
Re: [twitter-dev] Re: Add a retweet button on the Twitter apps definition box!
Thanks for the idea guys. We'll consider it and see if we can put something together to help spread awareness of apps. Best, Ryan On Mon, Nov 23, 2009 at 12:36 AM, Shyam thanash...@gmail.com wrote: In that case, twitter could use one of its official account (or create a new one), which tweets this. -- Yours, Thanashyam Raj. twitter.com/thanashyam
[twitter-dev] What are you doing? = What's happening? changes
Wanted to email everyone to point out the subtle, but important change on twitter.com. Today we have rolled out an update that changes the text above the tweet box from What are you doing? to say What's happening?. I could try to explain the reasons for the change, but that's Biz's job :) You can read about the thinking behind the change here: http://blog.twitter.com/2009/11/whats-happening.html For each app, it's up to you if you want to make the change or make it whatever you want -- we love the creativity. We will also be offering translations for it and all of our other standard strings. If you haven't seen the translations page on the wiki, check it out and keep checking back in as we bring other languages online - http://apiwiki.twitter.com/Twitter-String-Translations. Read the post and let us know what you think of the change. Ryan
[twitter-dev] Maintenance window Tuesday, November 17th at 11p Pacific
Cross posting here from status.twitter.com: On Tuesday, November 17th, we will be upgrading network equipment between 11p and 1a Pacific. The site may be unavailable for short periods in that window. Let us know if you have any questions. Ryan
[twitter-dev] Re: Social Graph Methods: Removal of Pagination
I just wanted to add some additional color to this as it didn't come through well in our email announcement. The actual change is happening Monday morning. Our email unfortunately said today as we were planning to send it the day of, but we ended up sending it earlier to give more notice and forgot to update the language. To your point, our team specifically choose Monday morning so people wouldn't have to be working on the weekend to fix things. We definitely have heard everyone in the past and are trying to ensure that all future changes like this happen early in the week and early in the day. Sorry again for the confusion, but we are listening and learning :) thanks for your patience and hard work and hope everyone is having a good weekend. Best, Ryan On Fri, Nov 13, 2009 at 10:45 PM, Tim Haines tmhai...@gmail.com wrote: Just like everyone knew the twitpocalypse was coming - but people still got burnt - even some high profile apps. An earlier day in the week is prudent if it's a planned change. On Sat, Nov 14, 2009 at 7:14 PM, Josh Roesslein jroessl...@gmail.com wrote: Well I think most issues should have been long resolved by now. Cursors have been live for a while now and there was plenty of warning ahead of today. The turn off should have no affect if you have ported to Cursors. On Fri, Nov 13, 2009 at 11:25 PM, Naveen Ayyagari knig...@gmail.com wrote: I agree, friday is a poor time to make planned changes to the API... On Nov 13, 2009, at 11:58 PM, Jesse Stay wrote: I've already implemented this, but for future sanity, can you guys avoid doing these major updates on Fridays when we're all not focusing as much on work? That way if there happen to be any bugs or problems our weekends aren't ruined. This seems to be a frequent occurrence on the Twitter API. Thanks, Jesse On Fri, Nov 13, 2009 at 3:03 PM, Wilhelm Bierbaum wilh...@twitter.com wrote: As previously announced by Alex Payne on September 24th (see http://bit.ly/46x1iL), we're removing support for pagination from the / friends/ids and /followers/ids methods. As of that time we set a hard deadline of October 26th, 2009. The original date has passed as we tried to give all of our partners extra time, but we are going to need to make the change now. At some point today, the page and count parameters will be ignored by the /friends/ids and /followers/ids methods and we will only be supporting cursors. Unfortunately, due to architectural considerations, cursor identifiers are not predictable. This means that you will have to extract the next and previous cursor identifiers from the results returned to you. For example, to get Obama's followers, we would first perform a GET against: http://twitter.com/followers/ids/barackobama.xml?cursor=-1 Which returns XML similar to: id_list ids id30592818/id (... more ids ...) /ids next_cursor1319042195162293654/next_cursor previous_cursor-8675309/previous_cursor /id_list To retrieve the next 5000 IDs, we would then perform a GET against: http://twitter.com/followers/ids/barackobama.xml?cursor=1319042195162293654 Note that cursors are signed 64-bit integers. Please refer to the documentation for our social graph methods for more information: http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends+ids http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers+ids Thanks!
[twitter-dev] Changes to search results for trending topics
Today on the Twitter Blog we announced that we will be changing search results for trending topics to improve the quality. It used to be that trends were a great way to quickly see what was going on on Twitter, but they have begun to get fairly noisy due to the sheer volume of tweets. We wanted to improve that experience and will start returning what we think are the best results. This doesn't mean that tweets are getting dropped from the index, instead we are just making intelligent decisions on which ones to return for searches on popular topics, beginning with trending topics. If you make a more specific search, you can still get to all the tweets. So for you, the developer, this means that if you will see better quality results over the search API for trends, but you won't be getting every tweet that matched the search term. If you still do want to get every tweet matching a trend, we recommend you check out the Streaming API (http://apiwiki.twitter.com/Streaming-API-Documentation). In the end, this is a change that is good for developers and end-users, but we wanted to notify you as you might be seeing some slightly different behavior via the API. Please let us know if you have any questions -- we are happy to answer. Ryan
[twitter-dev] Re: waiting for whitelisting
You can request whitelisting here: http://twitter.com/help/request_whitelisting On Wed, Nov 4, 2009 at 11:27 AM, twittme_mobi nlupa...@googlemail.com wrote: Hello, Sorry for posting this again. but I have problems with my mobile twitter site, which is in production since 4 months now and alreay widely used.The problem is that my hosting company changed my outgoing IP without notifying me and now i reach the time limit and the users are complaining.It is very annoying so i would kindly ask the twitter guys to have a look. My new IP is 99.198.100.139 for http://twittme.mobi and i would like to have it whitelisted. Thanks.
[twitter-dev] Re: Very slow response with API from Slicehost
Guys, Thanks for the reports. We are aware of the elevated 50xs and are working hard to bring it back down to normal. I don't have a specific timeline that I can give at this point, but we'll update you regularly if this continues. I've update @twitterapi with the latest status as well: http://twitter.com/twitterapi/status/5047567434 As for the follow up regarding this weekends issue, we are still committed to giving that report, but we haven't gotten all the details yet. We will update the list when we can produce a full issue report. Thanks, Ryan On Wed, Oct 21, 2009 at 9:42 AM, Hwee-Boon Yar hweeb...@gmail.com wrote: Like I have mentioned privately to someone: Can I then make a next best suggestion that is most easy to implement and yet effective? It has been suggested more than once. Post an update to status.twitter.com. Even a short message. Give us something to retweet, to forward to users. If you want to know the impact on 3rd party developers, go to iTunes App Store on your iPhone (I assume you use one) and read the top few reviews for SimplyTweet. They mention performance problems and loading errors of SimplyTweet. snip. Tell me how this doesn't hurt us? Do you not agree that not posting updates under situations like this (where you know it has been under heavy load for a couple of days) reflects policy rather than lack of 3rd party developer support resources? If fact, I'll be blunt and say that this policy directly suggests to me, as a 3rd party developer, that Twitter doesn't care about us and is even letting us help shield Twitter from user complaints. -- Hwee-Boon On Oct 22, 12:29 am, Michael Steuer mste...@gmail.com wrote: No, seeing the same since Saturday. @rsarver said on Sunday morning he would post information to the group once they knew what was causing all this, but I guess 4 days later they still don't know, as we haven't heard anything... On 10/21/09 9:05 AM, RandyC bioscienceupda...@gmail.com wrote: I have been seeing enormous numbers of 502's and 500's for API calls from Qwest DSL business, Rackspace, and Amazon Cloud instances since Saturday through today. Working through the UI to log into accounts is equally painful with constant fail whales after two to three attempts. Seems like a couple of bad hair days so far and very difficult to get much done. I'm surprised more people aren't talking about this unless we're the only ones affected.
[twitter-dev] Re: Problems Connecting to the API
I wanted to check in and see if everyone is back to normal? We think things have been fixed but its hard to confirm without your help. Let me know if you are still experiencing any issues and if so, where you are located. Best, Ryan On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius dpr...@gmail.com wrote: Same here. Can connect again. On Oct 18, 2:46 pm, Michael Steuer mste...@gmail.com wrote: The situation seems to have been resolved, at least for me, as of a few minutes ago. My Rackspace hosted servers can reach the API again... On Oct 18, 2009, at 10:35 AM, Dewald Pretorius dpr...@gmail.com wrote: I don't really blame Twitter Ops for not knowing. It's probably a new edge defense that was installed by their service provider during Sunday night. However, a while ago Alex said the Platform team were working on an external monitoring solution. Hopefully Ryan, who is now Director of the Platform team, will quickly move this forward to completion. Dewald On Oct 18, 1:30 pm, Michael Steuer mste...@gmail.com wrote: Amen to that. I find it kind of curious that as per John K., 5-6 hours into this issue, the Twitter ops team was still blissfully unaware of anything going on... Also weird that they apparently are unable to reproduce the issue without our help, ie. they really haven't set up any monitoring outside of their network... On Oct 18, 2009, at 9:05 AM, Dewald Pretorius dpr...@gmail.com wrote: I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer mste...@gmail.com wrote: This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer john.l.me...@gmail.com wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients).
[twitter-dev] Re: Problems Connecting to the API
Dewald, Can you produce some TCP dumps and requests with headers so we can better debug? Thanks, Ryan On Sun, Oct 18, 2009 at 12:05 PM, Dewald Pretorius dpr...@gmail.com wrote: I'm seeing lots of 502's now. Is the API overloaded? Dewald On Oct 18, 2:58 pm, Ryan Sarver rsar...@twitter.com wrote: Michael, We are still working on getting the full picture, but once we have the details I will report to the group what the issue was. Thanks for updating us. Best, Ryan On Sun, Oct 18, 2009 at 10:55 AM, Michael Steuer mste...@gmail.com wrote: It is working for me. Would you mind sharing with the group what exactly happened? Thanks. Michael On Oct 18, 2009, at 10:53 AM, Atul Kulkarni atulskulka...@gmail.com wrote: Works Fine... Duluth, MN. On Sun, Oct 18, 2009 at 12:51 PM, Ryan Sarver rsar...@twitter.com wrote: I wanted to check in and see if everyone is back to normal? We think things have been fixed but its hard to confirm without your help. Let me know if you are still experiencing any issues and if so, where you are located. Best, Ryan On Sun, Oct 18, 2009 at 10:48 AM, Dewald Pretorius dpr...@gmail.com wrote: Same here. Can connect again. On Oct 18, 2:46 pm, Michael Steuer mste...@gmail.com wrote: The situation seems to have been resolved, at least for me, as of a few minutes ago. My Rackspace hosted servers can reach the API again... On Oct 18, 2009, at 10:35 AM, Dewald Pretorius dpr...@gmail.com wrote: I don't really blame Twitter Ops for not knowing. It's probably a new edge defense that was installed by their service provider during Sunday night. However, a while ago Alex said the Platform team were working on an external monitoring solution. Hopefully Ryan, who is now Director of the Platform team, will quickly move this forward to completion. Dewald On Oct 18, 1:30 pm, Michael Steuer mste...@gmail.com wrote: Amen to that. I find it kind of curious that as per John K., 5-6 hours into this issue, the Twitter ops team was still blissfully unaware of anything going on... Also weird that they apparently are unable to reproduce the issue without our help, ie. they really haven't set up any monitoring outside of their network... On Oct 18, 2009, at 9:05 AM, Dewald Pretorius dpr...@gmail.com wrote: I'd be more than happy to wait longer for snazzy API 2.0 features so that the Platform team can build a QoS system that monitors the API's availability and performance from the outside. That will enable Twitter to catch these kinds of issues long before we do. Dewald On Oct 18, 12:47 pm, Michael Steuer mste...@gmail.com wrote: This outage is now going on 7 hours. Any word from Twitter as to an ETA for resolution? On Oct 18, 2009, at 8:08 AM, John Meyer john.l.me...@gmail.com wrote: John Kalucki wrote: And here's the next question: Is anyone having trouble from non-service, non-hosted endpoints. In other words, problem from home ISPs and desktop clients? -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. Yep. (comcast, cannot access through either the website or desktop clients). -- Regards, Atul Kulkarni www.d.umn.edu/~kulka053
[twitter-dev] Re: Duplicate Tweets
I appreciate the healthy debate here over the issue, and we all read the threads in this forum, but the reality is we don't have the time to respond to every inquiry. Chad has done a great job in making sure explicit questions get answered and we are happy to have an open discussion about the topic. Let me try to answer the myriad of topics that have been raised here: 1. Duplicate tweets HAS always been considered a violation. If you haven't read The Twitter Rules (clearly linked to from the Terms), you should read them now: http://help.twitter.com/forums/26257/entries/18311. It clearly states under *Spam* that the definition will include ... post duplicate content over multiple accounts or multiple duplicate updates on one account 2. In the Spam section of that policy we also clearly state that the rules will be changing as we adapt to new tactics. It's an arms race and we need the ability to react to new issues to protect the experience for all users and developers. And counter to Dewalds point, releasing exact numbers for spammers to circumvent creates MORE of an issue, not less. If you are dancing around the edges of those numbers, you are likely supporting functionality that questionable. 3. Spam is bad. For everyone. We will not only enforce the letter of that document but the spirit of that document. If your app enables spam, be prepared to get an email from us. We will help you identify the features that are facilitating spammy behavior and work with you to rectify it. 4. We are open with our policies and communication. If you have questions about your app, please email us for clarification. We are happy to talk to you about it. Best, Ryan On Tue, Oct 13, 2009 at 7:46 PM, Dewald Pretorius dpr...@gmail.com wrote: I've previously asked for guidelines on what our responsibilities are in terms of self-policing. No answer. Add to that the clear and unambiguous definition of things. Yeah sure, Twitter cannot clearly define things because that will aid the spammers. Bullshit. It is their responsibility to define what exactly is acceptable to them. That will not assist the spammers. It will assist us to not inadvertently, through wrong interpretation or assumption, provide a platform that spammers can leverage. Up until the first email I received from Twitter on October 8th, I was monitoring the level of duplicate tweet rejection that the API was giving, and I consequently concluded that the users of my service was not producing a large amount of duplicate tweets. Seems like their internal definition of duplicate content is far wider than the interpretation of the Platform Team when they wrote the code to reject duplicate tweets. I still do not know exactly what is duplicate content and what is not. Do you? I guess not. Nobody knows. Dewald On Oct 13, 11:07 pm, PJB pjbmancun...@gmail.com wrote: Chad: Sorry, I didn't see you had posted in here, and not sure if my subsequent posts properly answered you. I mean that Desktop apps, not being bound by a whitelisted IP, wouldn't be limited by restrictions limiting API access to OAUTH only. Namely, a desktop client could use a Mozilla user-agent, scrape Twitter.com, grab an authenticity_token, and then do a simple HTTP form submission with plaintext username/password. From there, the client could do whatever outlawed actions aren't possible from Web apps. While you could presumably find some commonalities with these logins for a time, probably the only effective way to counter this approach is to introduce login captchas. And that's an ugly barrier to entry for the average user. Restricting Web-based apps will presumably shift the policed behavior to such desktop apps, where it would probably morph into something even more destructive. As a web-based developer, I've previously asked for guidelines on what our responsibilities are in terms of self-policing. No answer. And it's really disheartening to hear that carte blanche limitations are now being imposed. There are obvious legitimate uses for recurring dynamic tweets (e.g., NBC announcing show schedules/guests, or fitness apps tweeting how many miles you ran). Blocking such behavior across the board seems incredibly short-sighted and limits further important business- oriented development in this area. PB On Oct 13, 12:47 pm, Chad Etzel c...@twitter.com wrote: On Tue, Oct 13, 2009 at 3:38 PM, PJB pjbmancun...@gmail.com wrote: Wrong. Basic Authentication will obviously ALWAYS be an option for desktop clients, regardless of whether or not it is via API. Please explain this statement? -Chad Furthermore, the app in question explicitly offered the option of a recurring tweet which is a violation of the TOS. Regardless of whether or not that provides a useful service -- I'm not going to start debating that -- the fact of the matter is it *is* a violation of the
[twitter-dev] Re: The little twitter button
Dave, It depends on which button you are seeing. A lot of blogs and sites have integrated Sign in with Twitter. It allows you to easily leverage Twitter for authentication and to link their identity on your site. http://apiwiki.twitter.com/Sign-in-with-Twitter Check it out and let us know if you have any questions. Best, Ryan On Wed, Oct 14, 2009 at 7:05 PM, Dawg ad...@sailinganarchy.com wrote: How do I get the little twitter button I see on many blogs and sites? I have set up FaceBook to work with our database of articles but I cannot find on twitter what I need to do. I don't think I need to use the Twitter API and I cannot find any information on this issue. Thanks Dave
[twitter-dev] Re: The Difference Between a Twitter Web and Desktop Application
Isaiah, We are definitely interested in hearing what type of workflow you would prefer for OAuth-ing desktop applications. We want to make the experience the best it can be and look for your feedback on how we can improve it. Let me start another thread so we can make sure to capture everyone's feedback. Best, Ryan On Sun, Oct 11, 2009 at 12:42 PM, Isaiah supp...@yourhead.com wrote: Like Chris, my app uses a similar UI. I released it as open source several months ago: http://github.com/yourhead/OAuth_ObjC_Test_App It hasn't seen runaway traffic, but it has been downloaded pretty constantly for about three months. There are now also several github clones of the project too. I think it's safe to assume that there are quite a few developers doing the same thing. As we've all seen, there is backlash from users and the media about the OAuth experience: http://twitter.com/gruber/status/4482717284 Judging from the feedback I received, it's safe to say that developers are looking for ways of making this less painful for the Twitter community, i.e. developers are doing this because they believe it will **help** users, not for some malicious reason. Those were definitely my goals. :-) If Twitter thinks this sort of UI is a bad idea, it sure would be nice to get some official feedback about it. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 11, 2009, at 9:28 AM, Abraham Williams wrote: Currently not really. Twitter might start enforcing correct designation at some point though. Abraham On Fri, Sep 25, 2009 at 12:33, cnunciato cnunci...@gmail.com wrote: Hi folks: I'm adding some Twitter integration to a desktop app, and I'm unhappy with the whole copy/paste this PIN into your application experience. In my case, I happen to have a browser instance containing the OAuth authentication process embedded within my desktop app, so it's possible to listen for redirection events that happen inside that browser and respond to them -- but when I mark my Twitter app as a desktop app (on the app-settings screen on Twitter, where it's defined), I'm forced into using the copy-this-PIN approach (because no callback URL can be specified for desktop apps), which, from a user- experience perspective, kinda sucks. I do notice, though, that if I make my app a web app instead, I can specify a callback URL, and have my app watch for redirections to that URL, which works quite well and provides a more seamless user experience. So my question is, is there any disadvanage to marking my installed desktop app a web app on Twitter, so I can take advantage of using a callback URL to provide a better user experience? Is it a violation of terms of use or anything? Any drawbacks at all? Thanks in advance -- Chris -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham http://web608.org/geeks/abraham/blogs/2009/10/03/win-google-wave-invite This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] OAuth wed desktop feedback
Hey everyone, I wanted to email the list to start gathering some feedback on how we can improve the OAuth workflow. As we have discussed in the past, Basic Auth is going to be deprecated at some point in the future for OAuth and we want to make sure we improve the experience to meet everyone's needs. I am interested in capturing feedback for both the web and desktop workflows. 1. What can be improved about the web workflow? 2. What can be improved about the desktop workflow? 3. What other models of distributed auth do you think we could learn from and what specifically about them? 4. What could we improve around the materials for integrating OAuth into your application? We really appreciate your feedback. Best, Ryan
[twitter-dev] Re: Twitter Geo stuff
Axthelm, If geo_enabled is set to false at the time you post geo data it will be dropped when it arrives and won't be saved for later tagging. Best, Ryan On Mon, Oct 12, 2009 at 3:23 PM, Axthelm caxth...@openpathproducts.com wrote: Excellent, thank you both for your responses. A second question on all of this, if the user has their geo_enabled flag off and we submit the location with their tweet will that location information be saved with the tweet for future use or disgarded due to the setting being off? Axthelm On Oct 9, 8:10 pm, Ryan Sarver rsar...@twitter.com wrote: There is going to be a read-only geo_enabled flag on the user object that denotes whether or not the user has enabled geolocation. For security reasons, the user will need to come to twitter.com to change the setting. Best, Ryan On Fri, Oct 9, 2009 at 8:18 AM, Axthelm caxth...@openpathproducts.com wrote: On that note, is it known if the setting to opt in will be exposed in the account/update_profile API? On Oct 4, 4:13 am, Rich rhyl...@gmail.com wrote: TheGeotag is only populated firstly if the user posting the tweet has opted in via Twitter's website (which hasn't been enabled yet) and secondlyGeodata was submitted with that tweet On Oct 4, 4:41 am, Patrick kenned...@gmail.com wrote: I have been reading about the TwitterGeostuff - it all sounds exciting - and I'd like to start playing with it even it's not fully prime time. Supposedly it's available to some extent via the API. I see the geo/ tag in my feed, and I wonder how I can opt in and get it populated. Also, can someone provide an example of how the location field could be populated - I have cURL examples to update location, and I have my location info via my Nokia GPS-assisted phone, so I'd like to see an example on now to simulate the future geo/ feature, i.e., update location field as if it were geo/, if I cannot yet opt in to geo/.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text -
[twitter-dev] Re: Twitter Geo stuff
There is going to be a read-only geo_enabled flag on the user object that denotes whether or not the user has enabled geolocation. For security reasons, the user will need to come to twitter.com to change the setting. Best, Ryan On Fri, Oct 9, 2009 at 8:18 AM, Axthelm caxth...@openpathproducts.com wrote: On that note, is it known if the setting to opt in will be exposed in the account/update_profile API? On Oct 4, 4:13 am, Rich rhyl...@gmail.com wrote: TheGeotag is only populated firstly if the user posting the tweet has opted in via Twitter's website (which hasn't been enabled yet) and secondlyGeodata was submitted with that tweet On Oct 4, 4:41 am, Patrick kenned...@gmail.com wrote: I have been reading about the TwitterGeostuff - it all sounds exciting - and I'd like to start playing with it even it's not fully prime time. Supposedly it's available to some extent via the API. I see the geo/ tag in my feed, and I wonder how I can opt in and get it populated. Also, can someone provide an example of how the location field could be populated - I have cURL examples to update location, and I have my location info via my Nokia GPS-assisted phone, so I'd like to see an example on now to simulate the future geo/ feature, i.e., update location field as if it were geo/, if I cannot yet opt in to geo/.- Hide quoted text - - Show quoted text -
[twitter-dev] Re: friends_timeline home_timeline broken
Thanks for pinging the list with this and confirming a few people are seeing it. I will follow up internally to figure out what is going on and report back here. Thanks again, Ryan On Thu, Oct 8, 2009 at 8:45 AM, stephane stephane.philipa...@gmail.comwrote: Echo, you are not alone Stephane @sphilipakis http://www.twazzup.com On Oct 8, 5:39 pm, Cameron Kaiser spec...@floodgap.com wrote: Errm it looks like the friends_timeline and home_timeline are broken, search seems to confirm this too. Basically I and many others have had no Tweets appear here for over an hour, yet I know 100% that there are users on my feed that have tweeted. Echoing this. I'm seeing this also. -- personal: http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- I think you underestimate the sneakiness.
[twitter-dev] Re: friends_timeline home_timeline broken
Ok, who broke Twitter? fess up... :) On Thu, Oct 8, 2009 at 8:54 AM, Rich rhyl...@gmail.com wrote: No problems, I think it's more than a few, try this search http://search.twitter.com/search?q=twitter+broken On Oct 8, 4:49 pm, Ryan Sarver rsar...@twitter.com wrote: Thanks for pinging the list with this and confirming a few people are seeing it. I will follow up internally to figure out what is going on and report back here. Thanks again, Ryan On Thu, Oct 8, 2009 at 8:45 AM, stephane stephane.philipa...@gmail.com wrote: Echo, you are not alone Stephane @sphilipakis http://www.twazzup.com On Oct 8, 5:39 pm, Cameron Kaiser spec...@floodgap.com wrote: Errm it looks like the friends_timeline and home_timeline are broken, search seems to confirm this too. Basically I and many others have had no Tweets appear here for over an hour, yet I know 100% that there are users on my feed that have tweeted. Echoing this. I'm seeing this also. -- personal: http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- I think you underestimate the sneakiness.
[twitter-dev] Twitpocalypse II Update - Scheduled for Tuesday 9/22 at 11:30am PST
To give everyone another update, we are still on track to trigger Twitpocalypse II tomorrow (Tuesday 9/22) at 11:30am PST. We are trying to do it as early in the day as we can on our side to accommodate developers in other timezones. For those of you unaware of what the Twitpocalypse is (hopefully no one by now), Alex previously noted the Twitter operations team will artificially increase the maximum status ID to 4294967296 ... If your Twitter API application stores status IDs, please be sure that your datastore is configured to handle integers of that size. A few of us will be available in IRC if you need live support, otherwise email the list with any questions you may have. Best, Ryan
[twitter-dev] Re: Changes to Twitter TOS/Rules.
Hardip, Thanks for your email. Our intent is to stop spamming accounts. Your use does not fall into that category, but its good practice to be judicious when including a lot of links in your updates as it triggers a lot of the filters that try to catch spam. Best, Ryan On Tue, Sep 15, 2009 at 7:58 AM, HardipSingh mr.hardip.si...@gmail.com wrote: I am curious how the following rule impact those that are auto- tweeting job links to #jobs and the other twitter job boards. * If your updates consist mainly of links, and not personal updates; Does this mean that we are in violation of this rule if I have an account that is primarily responsible for tweeting job links? Thanks in advance for your time. ~ H
[twitter-dev] Re: Comments for the group and Twitter staff
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
[twitter-dev] Re: Paging STILL broken
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.
[twitter-dev] Re: Paging STILL broken
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.
[twitter-dev] Re: Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs!
To give everyone an update -- We have been able to work with our operations team to delay the forced update until around September 21st or 22nd (over a week away). Since this twitpocalypse is based on the tweet count, it is impossible to predict exactly when it will happen and therefore we can only make projections based on current usage and possible spikes. With that being said, it *could* happen as early as Sept 16th (Wednesday), so please start updating your applications now to handle the change. We will be able to give you better estimates as the event moves closer and we will be sure to update the list when we know the exact time of the update. Let us know if you have any questions and be sure to stock up on water and non-perishable goods :) Ryan On Thu, Sep 10, 2009 at 9:10 AM, Ivan Kiriginivan.kiri...@gmail.com wrote: Call me crazy, but I store any data from a 3rd party in strings. Typically, I used a text blob to store some serialized object (like json or a python pickle) which maximizes flexibility. For the tweet id, I think I used 64 chars. In about 10 years, after I've cleared all the other higher priority and more impactful optimizations, I might think about dealing with this again. Ivan http://kirigin.com On Sep 10, 5:48 am, JDG ghil...@gmail.com wrote: and if they are, just store the twos complement of the ID in the DB and do the math when you retrieve if it's negative. :) On Thu, Sep 10, 2009 at 00:12, Rob Ashton robash...@codeofrob.com wrote: I've always just stored as 64bit integers, I'd assumed that 32bit wouldn't be enough. Now, if it goes above 64bit then I'm screwed, because neither my language or database have built in support for that! :P *From:* JDG ghil...@gmail.com *Sent:* Thursday, September 10, 2009 4:21 AM *To:* twitter-development-talk@googlegroups.com *Subject:* [twitter-dev] Re: Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs! if you were on signed32 you'd have had a problem a long time ago. not quite sure why people haven't just taken to treating/storing as strings -- sure there's a bit more overhead mem/storage-wise, but you don't have to change your code every few months. On Wed, Sep 9, 2009 at 16:45, Joseph Cheek jos...@cheek.com wrote: Twitter is in league with Al Qaida! You heard it first here, folks! Ok, seriously, this message I wrote wasn't worth the electrons it took to transmit it... let's see if I can increase the s2n ratio: 4294967296, that an unsigned 32-bit int? ok, fair enough. i know some of my apps use signed 64bit ints, but i'm not sure about the db... will need to check... might be signed32... Joseph Cheek jos...@cheek.com,www.cheek.com twitter:http://twitter.com/cheekdotcom Nicholas Moline wrote: And nobody thought about the significance of accelerating anything called a *pocolypse to be on the anniversary of a date that thousands died in a terrorist attack Tactful Twitter... Real Tactful On Wed, Sep 9, 2009 at 1:00 PM, Alex Payne a...@twitter.com mailto:a...@twitter.com wrote: 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 mailto:hweeb...@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 mailto: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 -- Internets. Serious business. -- Internets. Serious business.
[twitter-dev] Re: Draft: Twitter Rules for API Use
Hey Jesse, thanks for the question. The intention here is to stop applications that are posting on the user's behalf without an explicit understanding of the action. There are some apps that post without the user giving permission each time, but the app needs to specify that at some point and the user needs to be fully aware of it. We should never see Sorry about that last post, app X sent it out without me knowing. That can mean different things for different applications, but its about setting the expectations properly so users are never surprised by what you as an app developer do on their behalf. We take user's reputations and voices seriously and all app developers should too. Make sense? Best, Ryan On Thu, Sep 10, 2009 at 6:10 PM, Jesse Stayjesses...@gmail.com wrote: This is great news! Regarding sending Tweets on a user's behalf, does that refer to DMs as well, and when seeking permission, must it be on a tweet-by-tweet basis, or can a user give you permission beforehand to have complete control over Tweeting on their behalf? I'd like to see that part clarified more. Thanks, Jesse On Thu, Sep 10, 2009 at 5:58 PM, Marcel Molina mar...@twitter.com wrote: To accompany our updated Terms of Service (http://bit.ly/2ZXsyW) we've posted a draft of the Twitter API rules at http://twitter.com/apirules. As the subject states, these rules are a work in progress and feedback is welcome. Please read the TOS announcement at http://bit.ly/2ZXsyW for some background. We encourage you to use the contact us link at http://twitter.com/apirules with any feedback you may have. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs!
Hwee-Boon, That is definitely part of the plan and hence why we are aiming for that Monday / Tuesday. We know what a strain it can be to push stuff out at the end of the week. Best, Ryan On Fri, Sep 11, 2009 at 10:27 AM, Hwee-Boon Yar hweeb...@gmail.com wrote: One suggestion: similar to API changes, it seems more appropriate that if you want to force it, to do it earlier in the week, starting Monday, rather than Friday. That leaves enough resources and hands to stock up water and non-perishable goods rather than on a Friday. -- Hwee-Boon On Sep 12, 12:27 am, Ryan Sarver rsar...@twitter.com wrote: To give everyone an update -- We have been able to work with our operations team to delay the forced update until around September 21st or 22nd (over a week away). Since this twitpocalypse is based on the tweet count, it is impossible to predict exactly when it will happen and therefore we can only make projections based on current usage and possible spikes. With that being said, it *could* happen as early as Sept 16th (Wednesday), so please start updating your applications now to handle the change. We will be able to give you better estimates as the event moves closer and we will be sure to update the list when we know the exact time of the update. Let us know if you have any questions and be sure to stock up on water and non-perishable goods :) Ryan On Thu, Sep 10, 2009 at 9:10 AM, Ivan Kiriginivan.kiri...@gmail.com wrote: Call me crazy, but I store any data from a 3rd party in strings. Typically, I used a text blob to store some serialized object (like json or a python pickle) which maximizes flexibility. For the tweet id, I think I used 64 chars. In about 10 years, after I've cleared all the other higher priority and more impactful optimizations, I might think about dealing with this again. Ivan http://kirigin.com On Sep 10, 5:48 am, JDG ghil...@gmail.com wrote: and if they are, just store the twos complement of the ID in the DB and do the math when you retrieve if it's negative. :) On Thu, Sep 10, 2009 at 00:12, Rob Ashton robash...@codeofrob.com wrote: I've always just stored as 64bit integers, I'd assumed that 32bit wouldn't be enough. Now, if it goes above 64bit then I'm screwed, because neither my language or database have built in support for that! :P *From:* JDG ghil...@gmail.com *Sent:* Thursday, September 10, 2009 4:21 AM *To:* twitter-development-talk@googlegroups.com *Subject:* [twitter-dev] Re: Alert: Twitpocalypse II coming Friday, September 11th - make sure you can handle large status IDs! if you were on signed32 you'd have had a problem a long time ago. not quite sure why people haven't just taken to treating/storing as strings -- sure there's a bit more overhead mem/storage-wise, but you don't have to change your code every few months. On Wed, Sep 9, 2009 at 16:45, Joseph Cheek jos...@cheek.com wrote: Twitter is in league with Al Qaida! You heard it first here, folks! Ok, seriously, this message I wrote wasn't worth the electrons it took to transmit it... let's see if I can increase the s2n ratio: 4294967296, that an unsigned 32-bit int? ok, fair enough. i know some of my apps use signed 64bit ints, but i'm not sure about the db... will need to check... might be signed32... Joseph Cheek jos...@cheek.com,www.cheek.com twitter:http://twitter.com/cheekdotcom Nicholas Moline wrote: And nobody thought about the significance of accelerating anything called a *pocolypse to be on the anniversary of a date that thousands died in a terrorist attack Tactful Twitter... Real Tactful On Wed, Sep 9, 2009 at 1:00 PM, Alex Payne a...@twitter.com mailto:a...@twitter.com wrote: 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 mailto:hweeb...@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 mailto: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
[twitter-dev] Re: non json response
Ben, It's a known issue and we are trying to hunt it down. Can you please provide us with your source IP and an approximate time of when you saw it? Thanks, Ryan On Wed, Aug 26, 2009 at 7:00 AM, benben.apperr...@googlemail.com wrote: Occassionally i get back a 200 status html response from the json search api which look like this, most times the same search works fine, it just happens occassionally: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/ TR/1999/REC-html401-19991224/strict.dtd !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML Does anyone recognise what this kind of response means? Is it normal, or just beta-ish quirks?
[twitter-dev] Re: 200 errors
Rich, Can you provide your source IP that you are seeing this issue from? We can only dig into the logs if we know where your traffic is coming from. Thanks, Ryan On Tue, Aug 25, 2009 at 7:19 AM, Richrhyl...@gmail.com wrote: I'm now getting this error back again! On Aug 18, 4:39 pm, Rich rhyl...@gmail.com wrote: Thanks Ryan I've emailed the API email address On Aug 18, 4:21 pm, Ryan Sarver rsar...@twitter.com wrote: Chris, Rich, Seems like you aren't the only ones right now. I'm going to work with Ops to see if we can figure out where it is coming from. Can you provide us with a little more info so it will be easier to track this down? 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 nslookup 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. Thanks in advance, Ryan On Tue, Aug 18, 2009 at 4:57 AM, Richrhyl...@gmail.com wrote: I'm seeing this type of behaviour too and it's getting very frustrating. Basically I'm checking for status 200, then I'm checking for Content- Type XML. However from time to time I'm getting non XML back from this function. On Aug 9, 8:27 am, Chris Babcock cbabc...@asciiking.com wrote: This is what the200response is looking like: [u...@cl-t090-563cl bin]$ time curl -Lsim 10http://twitter.com/account/rate_limit_status.xml HTTP/1.0200OK Connection: Close Pragma: no-cache cache-control: no-cache Refresh: 0.1 Content-Type: text/html; charset=iso-8859-1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd; !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML real 0m0.100s user 0m0.002s sys 0m0.004s [u...@cl-t090-563cl bin]$ time curl -Lsim 10http://twitter.com/account/rate_limit_status.xml HTTP/1.1200OK Date: Sun, 09 Aug 2009 07:17:05 GMT Server: hi Last-Modified: Sun, 09 Aug 2009 07:17:05 GMTStatus:200OK ETag: d3498c2414150299df3cc1f6bb73b92c Pragma: no-cache Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 Content-Type: application/xml; charset=utf-8 Content-Length: 302 Expires: Tue, 31 Mar 1981 05:00:00 GMT X-Revision: 5a9a0d1ff0ba64c181510974278cfccc10e77d0b X-Transaction: 1249802225-83448-6420 Set-Cookie: _twitter_sess=BAh7BzoHaWQiJWVkNjk5Njk2YWNhNjQ3ZjgyOGQzNzdjNTAzMTE3ZjBmIgpm% 250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdX NlZHsA--639086f2287f85ef9e07f98d16adcce416b79e8d; domain=.twitter.com; path=/ Vary: Accept-Encoding Connection: close ?xmlversion=1.0 encoding=UTF-8? hash remaining-hits type=integer150/remaining-hits hourly-limit type=integer150/hourly-limit reset-time-in-seconds type=integer1249805825/reset-time-in-seconds reset-time type=datetime2009-08-09T08:17:05+00:00/reset-time /hash real 0m0.184s user 0m0.002s sys 0m0.003s In a browser that would be functionally the same as a 302, but I'mnot using a browser so the semantics are kind of important. It *seems* to happen whenever I hit the API with a cold request. Pure speculation. If I think of a way to test it, I will do so. Chris Babcock
