Re: [twitter-dev] Re: Are embedded videos available through the API?
that's precisely what the #newtwitter site does -- it looks at entities, and then makes decisions as to what to embed from the URLs that the API has extracted. -- Raffi Krikorian Twitter, Application Services http://twitter.com/raffi On Saturday, March 19, 2011 at 4:57 PM, Adam Green wrote: Thanks. I am aware of the entity URLs. I thought the API may have something else, but my guess is that the new UI does what I would do, which is look for URLs from known sources and then display them in the appropriate player. On Sat, Mar 19, 2011 at 7:51 PM, Tim Bull t...@trunk.ly wrote: Have you looked at embed.ly? You can use the entities to extract the URLs really easily too http://developer.twitter.com/pages/tweet_entities Tim On Mar 20, 10:44 am, Scott Wilcox sc...@dor.ky wrote: Hi Adam, I've not seen anything API side for it (for public use), I think mostly its built into the NewTwitter UI. Probably rendered inline. It'll be interested to see Ryan or Taylor respond to this, but I doubt there is anything for us to use. Scott. On 19 Mar 2011, at 23:38, Adam Green wrote: I have a client who wants to extract videos that are embedded in tweets and displayed in the new Twitter UI. I realized that I have never seen anything here about this issue. A check of the docs shows nothing on this, and using the relevant API calls for statuses doesn't return any fields related to embedded media. Is this available through the API? The other way I can see doing this is looking for entity URLs from YouTube and other video sites, but I was hoping there was something more direct. -- 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
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
Re: [twitter-dev] consistency and ecosystem opportunities
Agreed. On Mar 13, 2011, at 4:58, Scott Wilcox sc...@dor.ky wrote: Providing you don't participate in any spamming, I would think your application is perfectly safe. On 13 Mar 2011, at 11:51, Dustin Lennon wrote: I guess what I would like to know is since I'm a hobbyist, am I going to get my token revoked just because I write a client that is just for my use to better my skills in learning a specific programming language and share with others things I've learned. -Dustin This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Sun, Mar 13, 2011 at 1:22 AM, Rich rhyl...@gmail.com wrote: Hi Raffi So if I'm reading what you wrote correctly, simple clients that just display a timeline, post etc are thinking too small and there is no business there, something I can agree with. However many of us have, what I'd call a value added client. Sure we have the basics of a client, but we have what I'd like to think are added value services such as tweet scheduling, augmented reality of tweeters around you, user streams, draft management, and so much more. Are we to think that these are actually going to be fine for the time being, so long as obviously we comply with the ToS. What you guys seem to be saying though is don't build clients because it won't make money, but some people seem to fail to grasp some of us develop apps like this because we enjoy it... it's a hobby and a passion and that doesn't always involve tons of profit. Services such as Seesmic started out in the simple Client business, remember Twhirl, etc. Sure they grew into something enterprise, but most of us start out at the bottom and with the basics. Richard On Mar 13, 2:39 am, Raffi Krikorian ra...@twitter.com wrote: in reading your blog post, i think you're misunderstanding what @*rsarver*wrote. the API is open -- i personally love seeing all the innovation around getting content into twitter (/1/status/update). there is a cafe in france who's oven tweets whenever its done baking. that uses the platform to get content in there. there was a NYU project that enabled your plants to tweet when they needed water. that uses the platform to get content into twitter. then there are people who match tweets to context. seeing twitter in action with a television show, or a newspaper article, or a conference, or a band -- that's how people really understand and get twitter. they see it through the lens of what's happening in the world. what @*rsarver* said, effectively, was building a business around *simply*rendering /1/statuses/home_timeline was probably-not-the-best-thing-to-do. please go still innovate. just don't bet money on simply making an API call to grabbing a user's home_timeline and rendering it. that's thinking too small, and @*rsarver* is telling you that. On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley shannon.whit...@gmail.comwrote: I was hoping that Ryan was just a few weeks early for his April Fools' post. Don't build clients? It sounds like a bad joke. I wrote a letter to Ryan on my blog in response to this post: http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-rya... I know you guys can't be serious about this. Stage a mutiny if you have to, but don't let this boneheaded decision stand. -- Raffi Krikorian Twitter, Application Serviceshttp://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 -- 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
Re: [twitter-dev] Re: consistency and ecosystem opportunities
i, personally, totally concur. what i don't think anybody can do is fully predict what platforms twitter will develop for next (although, you probably can make a guess as you see market-share play out). what i would say is that, if you are building a twitter client, twitter, as a company, will probably hold you to a much higher bar than those who are not. we do have a strong opinion regarding rendering, display, interaction, etc. innovation, in my mind, is around doing something revolutionary, and not necessarily evolutionary. there is plenty to do out there that is not evolutionary. On Sun, Mar 13, 2011 at 8:34 AM, Jef Poskanzer jef.poskan...@gmail.comwrote: 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 -- 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
Re: [twitter-dev] Re: consistency and ecosystem opportunities
i don't think we've said its a waste of time, especially for something like dabr. and, again, its not that we're stopping the competition -- we've said that if you are building a regular timeline client, we're going to be holding you to a higher bar. in our opinion, its not a good -business- to be in. i would love to see dabr, and other smaller, niche clients that are done out of enjoyment of coding, love of programming, etc. to continue! On Sun, Mar 13, 2011 at 11:25 AM, artesea ryancul...@gmail.com wrote: Except every day I hear people go I hate new twitter, I want feature y, I wish it didn't do that. I run a port of dabr, I don't do it for the money (no ads on the site) I do it for the love of programming. Working out ways to get thumbnail images in to the timeline. To have different displays depending on the device or choice of the user. Being able to come up with an idea whilst at work, and 2 hours at the keyboard when I get home to have it working. The number of users on my client is probably five, but I'm finding it odd that Twitter insist that I'm wasting my efforts. If you are so confident that you have a large enough market of the timeline clients why stop competition? Ryan ps, I'm guessing that I'm counted in the 90% who use a twitter client, but it's install on my android device any is only used to sync up to my contacts. On Mar 13, 4:38 am, Raffi Krikorian ra...@twitter.com wrote: hey adam. i can't speak officially and definitively, however, we don't think there are as many business opportunities in making a piece of software that *simply* renders any of our timeline methods (/1/statuses/home_timeline,/1/statuses/mentions, lists, etc.). that's your #1. you're right, we do think there is a lot to be done with tweet summarization, curation, selection, matching, etc. focus your efforts on that and just follow our lead with tweet rendering and interaction. does that help? On Sat, Mar 12, 2011 at 7:45 PM, Adam Green 140...@gmail.com wrote: Can we get a definition of client? This seems to be where we are talking across each other. 1. Twitter HQ sees a client as an app that displays *only* a user's home time line and allows the user to tweet, retweet, follow, etc. 2. Developers see a client as an app that displays tweets from any source, including the home timeline *and* those that are curated by editors and algorithms, and allows the user to tweet, retweet, follow, etc. I think to Twitter HQ, these are two very different things. I believe that this is what Ryan was trying to say. I believe that Ryan was trying to say, don't build apps that *only* do 1. You will have more luck with 2. Developers heard don't build apps that do 2 or you will be instantly shut down. If Ryan hadn't combined his message with things that inadvertently also were perceived as a threat of instant shutdown as a result of an innocent misunderstanding of the rules, his statement would have been taken as advice, rather than a threat. I believe he meant well. He failed. He should keep trying until everyone understands. That is his job. Or it should at least be someone's job. Collectively the developers are worth the effort. Hey, why not hold a conference, put everyone together, and talk until this is clear? You can afford it. We all need it. Your future IPO investors aren't stupid. Well, at least not all of them. It is not just your revenue numbers they will see. It is lots of either happy or unhappy developers. We will raise your valuation. Keep saying that to Dick and the Board. They need to understand that. On Sat, Mar 12, 2011 at 10:26 PM, Raffi Krikorian ra...@twitter.com wrote: is the twitter client what's the most useful thing there? i would think the algorithms and system to match tweets to that content is the most fruitful place for entrepreneurship? On Sat, Mar 12, 2011 at 7:22 PM, Shannon Whitley shannon.whit...@gmail.com wrote: Thanks, Raffi, but obviously I'm not the only one reaching these conclusions. If our interpretation is incorrect, then the policy isn't clear. Television shows, newspaper articles, and band pages are perfect examples of places where a Twitter client might be useful. I could build a full-featured Twitter client around a single news site and that might be the perfect solution for that set of users. Under the new guidelines, it sounds like I'd be shutdown. On Mar 12, 6:39 pm, Raffi Krikorian ra...@twitter.com wrote: in reading your blog post, i think you're misunderstanding what @*rsarver*wrote. the API is open -- i personally love seeing all the innovation around getting content into twitter (/1/status/update). there is a cafe in france who's oven tweets whenever its done baking. that uses the platform to get content
Re: [twitter-dev] Re: consistency and ecosystem opportunities
there are two things: - twitter has started to specify what the core experience should be -- we have strong feelings around display and interaction; - twitter is poised to move extremely quickly. attempting to speak neutrally without any partisanship: IMO its a bad idea to create a business where you would have to bend at the whims of another organisation. the higher bar that we've been talking about is that scrutiny. Is Twitter saying We believe that a Twitter client will not make a lot of money. Go ahead and try but don't say we didn't tell you so if you make no money.? Or are you saying Don't go into the Twitter client business because we may shut you down at will for any reason? The other statement I keep seeing is that we'll be held to a higher bar. What does that mean? Does it mean new Twitter clients might be rejected the way Apple rejects new apps? Could existing apps be shut down because they fall beneath this bar? Will we be getting any documentation specifically telling us what the criteria are? Will Twitter be doing this for all clients, or just clients that exist on the same platform as an official app (iPhone, Android, etc)? What about clients that don't exist as part of a business, such as open source apps? -Costa -- 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
Re: [twitter-dev] Re: users/lookup returns duplicates, missing records for valid users
hi all. we're actively investigating this issue. On Fri, Mar 11, 2011 at 8:13 PM, gcoats84 gary.co...@gmail.com wrote: I am also running into these issues with users/lookup.json. The ids I have issues with are totally random. Sometimes the duplicates are back to back, other times they are separated by a few records. example screen names that are all returned duplicates: yaneeduh, JDH1127, MelxWeasley, ealderson, jennypenk, shubbs1, zx48k, Krausekid211, MissKellieBelly On Mar 9, 4:49 am, nischalshetty nischalshett...@gmail.com wrote: Hi, I too am getting duplicate results and some of the valid ids are not beings returned. If it helps, these ids would replicate all the issues faced : 11825, 248874232, 28296091, 251642658, 257793455, 225992183, 85168850, 92509004, 113697273, 99673641, 99253238, 98032551, 91619850, 47528631, 52652119, 14941300, 26403984, 33322905, 32162070, 24612782, 25218999, 20829096, 19491208, 18549369, 15074733, 13757662, 68889828 -N On Mar 2, 2:02 pm, David JULIEN da...@semiocast.com wrote: I have noticed this strange behaviour too (duplicated results and unknown users). For instance, yesterday, when I tried to lookup for user 44537294 (with two different accounts), I received during many hours information about user 243784138, before receiving expected result (around 17/18h UTC). David -- 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
Re: [twitter-dev] Re: consistency and ecosystem opportunities
in reading your blog post, i think you're misunderstanding what @*rsarver*wrote. the API is open -- i personally love seeing all the innovation around getting content into twitter (/1/status/update). there is a cafe in france who's oven tweets whenever its done baking. that uses the platform to get content in there. there was a NYU project that enabled your plants to tweet when they needed water. that uses the platform to get content into twitter. then there are people who match tweets to context. seeing twitter in action with a television show, or a newspaper article, or a conference, or a band -- that's how people really understand and get twitter. they see it through the lens of what's happening in the world. what @*rsarver* said, effectively, was building a business around *simply*rendering /1/statuses/home_timeline was probably-not-the-best-thing-to-do. please go still innovate. just don't bet money on simply making an API call to grabbing a user's home_timeline and rendering it. that's thinking too small, and @*rsarver* is telling you that. On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley shannon.whit...@gmail.comwrote: I was hoping that Ryan was just a few weeks early for his April Fools' post. Don't build clients? It sounds like a bad joke. I wrote a letter to Ryan on my blog in response to this post: http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-ryan-sarver/ I know you guys can't be serious about this. Stage a mutiny if you have to, but don't let this boneheaded decision stand. -- 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
Re: [twitter-dev] Re: consistency and ecosystem opportunities
is the twitter client what's the most useful thing there? i would think the algorithms and system to match tweets to that content is the most fruitful place for entrepreneurship? On Sat, Mar 12, 2011 at 7:22 PM, Shannon Whitley shannon.whit...@gmail.comwrote: Thanks, Raffi, but obviously I'm not the only one reaching these conclusions. If our interpretation is incorrect, then the policy isn't clear. Television shows, newspaper articles, and band pages are perfect examples of places where a Twitter client might be useful. I could build a full-featured Twitter client around a single news site and that might be the perfect solution for that set of users. Under the new guidelines, it sounds like I'd be shutdown. On Mar 12, 6:39 pm, Raffi Krikorian ra...@twitter.com wrote: in reading your blog post, i think you're misunderstanding what @*rsarver*wrote. the API is open -- i personally love seeing all the innovation around getting content into twitter (/1/status/update). there is a cafe in france who's oven tweets whenever its done baking. that uses the platform to get content in there. there was a NYU project that enabled your plants to tweet when they needed water. that uses the platform to get content into twitter. then there are people who match tweets to context. seeing twitter in action with a television show, or a newspaper article, or a conference, or a band -- that's how people really understand and get twitter. they see it through the lens of what's happening in the world. what @*rsarver* said, effectively, was building a business around *simply*rendering /1/statuses/home_timeline was probably-not-the-best-thing-to-do. please go still innovate. just don't bet money on simply making an API call to grabbing a user's home_timeline and rendering it. that's thinking too small, and @*rsarver* is telling you that. On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley shannon.whit...@gmail.comwrote: I was hoping that Ryan was just a few weeks early for his April Fools' post. Don't build clients? It sounds like a bad joke. I wrote a letter to Ryan on my blog in response to this post: http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-rya. .. I know you guys can't be serious about this. Stage a mutiny if you have to, but don't let this boneheaded decision stand. -- Raffi Krikorian Twitter, Application Serviceshttp://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 -- 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
Re: [twitter-dev] consistency and ecosystem opportunities
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 key areas where ecosystem developers are thriving: - *Publisher tools*. Companies such as SocialFlowhttp://www.socialflow.com/help publishers optimize how they use Twitter, leading to increased user engagement and the production of the right tweet at the right time. - *Curation*. Mass Relevance http://www.massrelevance.com/ and Suliahttp://www.sulia.com/provide services for large media brands to select, display, and stream the most interesting and relevant tweets for a breaking news story, topic or event. - *Realtime data signals*. Hundreds of companies use real-time Twitter data as an input into ranking, ad targeting, or other aspects of enhancing their own core products. Klout http://klout.com/ is an example of a company which has taken this to the next level by using Twitter data to generate reputation scores for individuals. Similarly, Gniphttp://gnip.com/syndicates Twitter data for licensing by third parties who want to use our real-time corpus for numerous applications (everything from hedge funds to ranking scores). - *Social CRM, entreprise clients, and brand insights*. Companies such as HootSuite http://hootsuite.com/, CoTweet http://cotweet.com/, Radian6 http://www.radian6.com/, Seesmic http://seesmic.com/, and Crimson Hexagon http://www.crimsonhexagon.com/ help brands, enterprises, and media companies tap into the zeitgeist about their brands on Twitter, and manage relationships with their consumers using Twitter as a medium for interaction. - *Value-added content and vertical experiences*. Emerging services like Formspring http://www.formspring.me/, Foursquarehttp://foursquare.com/, Instagram http://instagr.am/, and Quora http://www.quora.com/ have built into Twitter by allowing users to share unique and valuable content to their followers, while, in exchange, the services get broader reach, user acquisition, and traffic. A lot of Twitter’s success is attributable to a diverse ecosystem of more than 750,000 registered apps. We will continue to support this innovation. We are excited to be working with our developer community to create a consistent and innovative experience for the many millions of users who have come to depend on Twitter every day. As always, we welcome your feedback and questions. Best, Ryan @rsarver http://twitter.com/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 -- 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
Re: [twitter-dev] Re: consistency and ecosystem opportunities
hey adam. i can't speak officially and definitively, however, we don't think there are as many business opportunities in making a piece of software that *simply* renders any of our timeline methods (/1/statuses/home_timeline,/1/statuses/mentions, lists, etc.). that's your #1. you're right, we do think there is a lot to be done with tweet summarization, curation, selection, matching, etc. focus your efforts on that and just follow our lead with tweet rendering and interaction. does that help? On Sat, Mar 12, 2011 at 7:45 PM, Adam Green 140...@gmail.com wrote: Can we get a definition of client? This seems to be where we are talking across each other. 1. Twitter HQ sees a client as an app that displays *only* a user's home time line and allows the user to tweet, retweet, follow, etc. 2. Developers see a client as an app that displays tweets from any source, including the home timeline *and* those that are curated by editors and algorithms, and allows the user to tweet, retweet, follow, etc. I think to Twitter HQ, these are two very different things. I believe that this is what Ryan was trying to say. I believe that Ryan was trying to say, don't build apps that *only* do 1. You will have more luck with 2. Developers heard don't build apps that do 2 or you will be instantly shut down. If Ryan hadn't combined his message with things that inadvertently also were perceived as a threat of instant shutdown as a result of an innocent misunderstanding of the rules, his statement would have been taken as advice, rather than a threat. I believe he meant well. He failed. He should keep trying until everyone understands. That is his job. Or it should at least be someone's job. Collectively the developers are worth the effort. Hey, why not hold a conference, put everyone together, and talk until this is clear? You can afford it. We all need it. Your future IPO investors aren't stupid. Well, at least not all of them. It is not just your revenue numbers they will see. It is lots of either happy or unhappy developers. We will raise your valuation. Keep saying that to Dick and the Board. They need to understand that. On Sat, Mar 12, 2011 at 10:26 PM, Raffi Krikorian ra...@twitter.comwrote: is the twitter client what's the most useful thing there? i would think the algorithms and system to match tweets to that content is the most fruitful place for entrepreneurship? On Sat, Mar 12, 2011 at 7:22 PM, Shannon Whitley shannon.whit...@gmail.com wrote: Thanks, Raffi, but obviously I'm not the only one reaching these conclusions. If our interpretation is incorrect, then the policy isn't clear. Television shows, newspaper articles, and band pages are perfect examples of places where a Twitter client might be useful. I could build a full-featured Twitter client around a single news site and that might be the perfect solution for that set of users. Under the new guidelines, it sounds like I'd be shutdown. On Mar 12, 6:39 pm, Raffi Krikorian ra...@twitter.com wrote: in reading your blog post, i think you're misunderstanding what @*rsarver*wrote. the API is open -- i personally love seeing all the innovation around getting content into twitter (/1/status/update). there is a cafe in france who's oven tweets whenever its done baking. that uses the platform to get content in there. there was a NYU project that enabled your plants to tweet when they needed water. that uses the platform to get content into twitter. then there are people who match tweets to context. seeing twitter in action with a television show, or a newspaper article, or a conference, or a band -- that's how people really understand and get twitter. they see it through the lens of what's happening in the world. what @*rsarver* said, effectively, was building a business around *simply*rendering /1/statuses/home_timeline was probably-not-the-best-thing-to-do. please go still innovate. just don't bet money on simply making an API call to grabbing a user's home_timeline and rendering it. that's thinking too small, and @*rsarver* is telling you that. On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley shannon.whit...@gmail.comwrote: I was hoping that Ryan was just a few weeks early for his April Fools' post. Don't build clients? It sounds like a bad joke. I wrote a letter to Ryan on my blog in response to this post: http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-rya... I know you guys can't be serious about this. Stage a mutiny if you have to, but don't let this boneheaded decision stand. -- Raffi Krikorian Twitter, Application Serviceshttp://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
[twitter-dev] site maintenance
hi all. you may have seen on our status blog that we're going to do some site maintenance -- we don't anticipate any downtime. however, if any of you notice issues, please feel free to reach out via this list! thanks! -- Raffi Krikorian Twitter, Platform 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
Re: [twitter-dev] Ars Technica article
hi all. i've posted a brief response at http://mehack.com/oauth-and-the-twitter-api On Thu, Sep 2, 2010 at 11:59 AM, Clay Loveless c...@killersoft.com wrote: Hi guys, I'm really interested in the platform team's response to the Ars Technica article here: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars if wrapped: http://bit.ly/dhLkx7 What's the word, guys? -Clay -- Clay Loveless Founder w: http://killersoft.com t: @claylo -- 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?hl=en -- Raffi Krikorian Twitter Platform Team 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?hl=en
Re: [twitter-dev] Re: Change in error response objects
it is designed so that we can send multiple error codes back, but in practice, right now, we only send one. On Sun, Aug 29, 2010 at 4:25 PM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, Will the new error construct always be: [errors][code] [errors][message] Or can it be sometimes: [errors][0][code] [errors][0][message] [errors][1][code] [errors][1][message] -- 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?hl=en -- Raffi Krikorian Twitter Platform Team 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?hl=en
Re: [twitter-dev] Change in error response objects
what endpoints are you still seeing this error format under? the change
should have been reverted in the case that you were mentioning.
On Sun, Aug 29, 2010 at 9:00 AM, Marc Mims marc.m...@gmail.com wrote:
* Raffi Krikorian ra...@twitter.com [100827 06:03]:
hi all.
this is most certainly a mistake on our part - we'll be reverting this
change.
Raffi, we're still seeing these unexpected error structures. When will
the change be reverted?
-Marc
On Fri, Aug 27, 2010 at 4:45 AM, Cameron Kaiser spec...@floodgap.com
wrote:
It looks like error responses have changed, at least for users/show.
I used to get:
{error:User has been suspended}
Now, I get:
{errors:[{code:63,message:User has been suspended}]}
I'm seeing that too. When did this change?
--
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?hl=en
--
Raffi Krikorian
Twitter Platform Team
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?hl=en
Re: [twitter-dev] Change in error response objects
hi all.
this is most certainly a mistake on our part - we'll be reverting this
change.
On Fri, Aug 27, 2010 at 4:45 AM, Cameron Kaiser spec...@floodgap.comwrote:
It looks like error responses have changed, at least for users/show.
I used to get:
{error:User has been suspended}
Now, I get:
{errors:[{code:63,message:User has been suspended}]}
I'm seeing that too. When did this change?
--
personal:
http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com *
ckai...@floodgap.com
-- They told me I was gullible ... and I believed them.
---
--
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?hl=en
--
Raffi Krikorian
Twitter Platform Team
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?hl=en
Re: [twitter-dev] Change in error response objects
All newer API methods have been returning API error codes for a while now. We have been extremely sensitive to not breaking older behavior (for backwards compatbility reasons), so older methods still return the old format. We have been toying with the ability to get error codes on all methods if developers pass in a special parameter, or header, but we haven't gotten very far down that route yet. On Friday, August 27, 2010, Marc Mims marc.m...@gmail.com wrote: * Raffi Krikorian ra...@twitter.com [100827 06:03]: this is most certainly a mistake on our part - we'll be reverting this change. The new error format looks useful, especially if the error code allows us to deal with multi-lingual error messages consistently. Obviously, some advanced notice and consistency across the API will be helpful. I'm still very interested in seeing Twitter provide library developers with advanced notice under non-disclosure for changes like this. -Marc -- 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?hl=en -- Raffi Krikorian Twitter Platform Team 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?hl=en
Re: [twitter-dev] Re: XML format change???
hi all. i don't know of any format change - do you have an example we can look at? On Wed, Jul 7, 2010 at 2:55 AM, colin@digital.fco.gov.uk colin@digital.fco.gov.uk wrote: I'm getting similar problems. With the use of simplexml_load_file, it loads other xml fine but not twitters!!! On Jul 7, 6:55 am, Pete phousle...@gmail.com wrote: Did you change the XML format today our application which has worked for a year reading XML data all of the sudden does not function today? Was there a format change without notice? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Rate limits should be resetting now
we are currently sitting at 100% - so 350 calls/hour on oauth, and 150 calls/hour on basic auth. fingers crossed! On Wed, Jul 7, 2010 at 6:42 PM, isaiah isa...@mac.com wrote: Does this mean a return to previous rate limits as well? Or are we still getting the squeeze? Isaiah On Jul 7, 5:54 pm, themattharris thematthar...@twitter.com wrote: Hey everyone, We've been working on the rate limit issue which has been affecting many of you and believe we now have it fixed. As the issue affected people in different ways we want to be check your applications are working again. If your rate limit is still not resetting please email a...@twitter.com the following information: * The IP of the computer which is making the requests * A username you are making requests for * The time you tried to make the request * The request you were trying to make * Any response headers you received Thanks, Matt -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Friend and Follower count - since timestamp
unfortunately, we don't yet support that functionality. the list is sorted with the newest items being first - you could grab the first page, and then go backwards until you start to see data that you've seen before. On Mon, Jul 5, 2010 at 10:34 PM, nischalshetty nischalshett...@gmail.comwrote: My app http://justunfollow.com extensively uses the friends/ids and followers/ids API. Since twitter users have a lot of followers and friends and this API is paginated, I find it repetitive to use it. A since param that sends me all new friend and follower ids of a user along with the deleted ids (when someone stops being a friend or follower) would help a lot. I checked the documentation but found no mention of this. Please help! -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Geotagging broken when user is using a foreign language
can you all please provide a concrete example? i just geotagged a tweet from my test account, switched my test account to spanish, then successfully geotagged another tweet, switched to japanese, and then geotagged yet another tweet. On Tue, Jul 6, 2010 at 4:43 AM, Daniel Schroeder deeme...@googlemail.comwrote: Oh dear, thanks a lot for this info. I was trying for two days to get this working! Thanks! Daniel Am 06.07.2010 um 13:24 schrieb janole: Please see bug report 1725 - http://bit.ly/anxAiC Apparently, you cannot geotag tweets anymore when a user's account is configured to any non-English language. My client users started to report this error a couple of days ago. When they switch back to English (lang = en), everything's fine again and they can geo-tag their tweets. ole @ mobileways.de / @janole on Twitter / Symbian S60 Twitter client #Gravity -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] @mention messages appear in the timeline
another way of stating is to wonder how you handle the mismatch of the number of tweets the home and mentions timeline receives. most people do not want to miss any results in the mentions timeline, but a lot of people do not mind missing tweets in the home timeline. if you mash the two together, how do you make sure to deal with that mismatch. how would you juggle the two since IDs that you may want to work with either? one idea could be to let clients use the home timeline and mentions timeline separately to catch up with real time, and then get them both from there on out... On Tue, Jul 6, 2010 at 6:47 AM, John Kalucki j...@twitter.com wrote: I think the request is that @mentions are merged in with home_timeline. There may be desktop clients that support this functionality, for all I know. The risks are that some users receive a lot of @mentions, and their home timelines would be unreadable. So, it would have to be an option. Secondly, it would open another spam vector that would have to be addressed. We have considered this feature on www, but I don't know whatever happened to the idea. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Tue, Jul 6, 2010 at 7:24 AM, sh0w3r `uuh` sho...@gmail.com wrote: On 07/06/10 06:50, Raffi Krikorian wrote: i'm sorry, i'm not sure what you're asking. the mentions timeline has mentions information in it: http://dev.twitter.com/doc/get/statuses/mentions On Mon, Jul 5, 2010 at 12:12 PM, show3r sho...@gmail.com wrote: hi i want you to implement mention messages to appear in the timeline, wont you think that would give the idea of twitter a boost? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi no im asking, as i first hear of twitter, and the idea of public im messages, or timelines of life, and lifetime ... i thought i would be better to show the @ - at-messages for example @user_ralph said that too, should appear in the timeline. at the moment you have to click the userfield on the right side @user_abc ... to search in twitter for all mention messages, cant you implement mentions in the basic timeline, as messages from user you follow? do you understand what i mean? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Failed to validate oauth signature and token using ColdFusion8
hi carlos.
i'm sorry that i'm not sure i can help to debug this code right now. if you
are going to insist on creating your own functions to do the oauth
signature, please consult
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/as
its a great interactive walk through. however, i would
*strongly* recommend using a library if possible. a simple google search
turned up http://oauth.riaforge.org/.
On Mon, Jul 5, 2010 at 10:42 AM, Carlos Villarreal Mora cvm...@gmail.comwrote:
Hello I've been trying to solve this since Friday to no avail. I've
searched and used tips from a bunch of other discussions here but I
still haven't gotten it right.
I'm using ColdFusion 8 to generate my OAuth signature. These are the
tweaks I've done from tips in this discussion list:
1) For the timestamp I convert to UTC time with this function:
var nowUTC = dateConvert('local2UTC', now());
var epochStart = CreateDateTime('1970','1','1','00','00','00');
var timestamp = dateDiff(s, epochStart, nowUTC);
This results in these values:
nowUTC = {ts '2010-07-05 17:22:30'}
epochStart = {ts '1970-01-01 00:00:00'}
timestamp = 1278346950
2) For the Nonce I use ColdFusion's createUUID function and then,
based on this (http://www.cflib.org/udf/CreateGUID) from CFLib.org I
convert that UUID into a GUID like so:
var uuid = createUUID();
//Convert the UUID to a GUID by inserting a dash in the 23rd
position
var nonce = insert(-, uuid, 23);
This is an example of a resulting nonce:
A3A1648E-F1F0-4032-75F4-712F676BE7E6
3) The most difficult part, and where I'm sure the error is, is the
SHA1 hashing, ColdFusion sucks at it so I'm using Java in the
function:
cffunction name=javaHMAC returntype=string access=public
output=false
cfargument name=signKey type=string
required=true /
cfargument name=signMessage type=string required=true
/
cfscript
var jMsg =
javaCast(string,arguments.signMessage).getBytes(UTF8);
var jKey =
javaCast(string,arguments.signKey).getBytes(UTF8);
var key =
createObject(java,javax.crypto.spec.SecretKeySpec);
var mac = createObject(java,javax.crypto.Mac);
var ret = ;
key = key.init(jKey,HmacSHA1);
mac = mac.getInstance(key.getAlgorithm());
mac.init(key);
mac.update(jMsg);
ret = lCase(binaryEncode(mac.doFinal(), 'Hex'));
return(ret);
/cfscript
/cffunction
When I sign the base using my Consumer Secret appended by a using
this function the result is something like this:
01eb730a110b1e09ccc9bbff9dbca73c5047f4d4
Here's the Signature Base and the Header I create (my consumer key is
masked for security reasons):
- Signature Base:
POSThttps%3A%2F%2Fapi%2Etwitter%2Ecom%2Foauth%2Frequest
%5Ftokenoauth_callback%3Dhttp%3A%2F%2Fcommunitydev%2Epaperthin%2Ecom
%2FTwitter%2FoAuth%2Ecfm%26oauth_consumer_key%3D
%26oauth_nonce%3DA394B8B8-
F1F0-4032-72C8-701CEC482A20%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1278328119
- OAuht Authorization Header:
OAuth oauth_nonce=A394B8B8-F1F0-4032-72C8-701CEC482A20,
oauth_callback=http%3A%2F%2Fcommunitydev%2Epaperthin%2Ecom%2FTwitter
%2FoAuth%2Ecfm, oauth_signature_method=HMAC-SHA1,
oauth_timestamp=1278328119, oauth_consumer_key=xxx,
oauth_signature=4799dd5a6891474d603a3546c14e9b41ea47088d,
oauth_version=1.0
There are no line breaks in either of them btw. Can anybody help me
with this? Try as I might I haven't been able to get beyond the
Failed to validate oauth signature and token response.
Thank you.
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] Geo XML Format Query
hi steve. there are two different ways to geotag a tweet. there is geotagging with an exact latitude and longitude, and then there is geotagging with a place. when you geotag with an exact latitude and longitude, the coordinates (and geo) attributes will be filled. additionally, if twitter has data for that area of the world, we will also immediately populate the place attribute with the contextual information. it is possible that we don't have data for that location, at which point the place attribute will be empty. you can also geotag with a place -- that's a neighborhood, a city, state, point of interest, etc. when somebody does that, only the place attribute is filled. take a look at http://api.twitter.com/1/statuses/show/17536619739.xml as that has all the fields populated. hope that helps! On Mon, Jul 5, 2010 at 10:56 AM, Steve 25tol...@gmail.com wrote: Hi all, I've done a search here for this info, and looked through the docs, but I can't find what I'm looking for documented anywhere. What I'm after is a full sample of what data might appear in the geo/ , coordinates/ and place/ tags, when they're populated. At present I've only seen some inner georss:point tags, but I'm curious what else may appear within these. I'm creating a tweet backup type thing, and pulling out various data items from the tweet to stick into SQL and analyse, and knowing what data might be in here would be handy. Thanks! -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] @mention messages appear in the timeline
i'm sorry, i'm not sure what you're asking. the mentions timeline has mentions information in it: http://dev.twitter.com/doc/get/statuses/mentions On Mon, Jul 5, 2010 at 12:12 PM, show3r sho...@gmail.com wrote: hi i want you to implement mention messages to appear in the timeline, wont you think that would give the idea of twitter a boost? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Home_timeline and retweets
i don't think ridiculous is the right term :P we're constantly evolving the API to match up with what our developers are trying to do! so - that being said - what are you looking for? are you trying to figure out which tweets on the home timeline has the authenticating user retweeted? On Mon, Jul 5, 2010 at 2:58 PM, luisg luisfmgoncal...@gmail.com wrote: So, instead of 1, now I have to do 2 call (one for the home_timeline and another for the retweets_of_me). I started to understand the 'Tiwtter is over capacity' error! ...ridiculous... On Jul 5, 6:17 pm, Thomas Woolway priv...@tswoolway.co.uk wrote: I don't think that you're doing anything wrong - it's just a quirk of the API - you don't get any info in your home timeline on stuff you retweeted. I think this is because of the condition that you should never see a retweet if you would have seen it already in your timeline. This stops you from seeing the latest popular tweet retweeted 100 times from each of your followers if you follow the person who originally tweeted it. However, I guess it also stops you seeing that you have retweeted a tweet, as theoretically you've already seen it. I think I've made that more complicated than it actually is... The only thing that you can do is to get the Home Timeline and then merge retweets_of_me in over the top. Tom On Mon, Jul 5, 2010 at 4:03 PM, luisg luisfmgoncal...@gmail.com wrote: Can somebody help? Maybe I'm doing something wrong. For example, if account A has Account B as follower and vice-versa, and if account A retweets tweet XPTO made by account B, shouldn't the tweet XPTO appear with retweet_status property if we request the home_timeline? Please help, Luis On Jul 3, 4:45 pm, luisg luisfmgoncal...@gmail.com wrote: Hello everybody, I'm having a problem lately with the retweets. In the API documentation and about the home_timeline says: 'Returns the 20 most recent statuses, including retweets, posted by the authenticating user and that user's friends. This is the equivalent of /timeline/home on the Web.' The problem is, when I request the home_timeline, none of my tweets have the 'retweeted_status' that should be present if it is a retweet. But if I request 'retweeted_by_me' I get all the information, including the 'retweeted_status'. Can someone tell me what's wrong? Something changed? Thanks, Luis -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Invalid timescale error on location trends
hey heidi. can you provide more information? i just tried the following few things: http://api.twitter.com/1/trends/2487956.xml (trends in SF) http://api.twitter.com/1/trends/2487956/current.xml (same as above) http://api.twitter.com/1/trends/2487956/hourly.xml (hourly version of trends from SF) http://api.twitter.com/1/trends/2487956/daily.xml (the day's trends from SF) and those worked. what's the exact call you're trying? On Mon, Jul 5, 2010 at 2:35 PM, Heidi Hysell heidi.hys...@gmail.com wrote: I'm trying to use the trends/location/woeid functionality (http:// dev.twitter.com/doc/get/trends/location/:woeid) and keep on getting the following error: code: 31 message: Invalid timescale: must be 'current', 'hourly', or 'daily' The documentation doesn't specify anything about sending in a timescale. I try and send in the timescale=current as a parameter, however it still gives me the same error. I've tried using different woeid's and they all result in the same error. Using the twitter provided console also yields the same error (http:// dev.twitter.com/console). Any insight is appreciated. Thanks, Heidi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] How can I check xauth request approved?
it takes a few days for us to process xauth requests - you should hear back from us soon! On Sun, Jul 4, 2010 at 7:57 PM, Nara ijwc...@gmail.com wrote: I sent email to request xauth access, and I got reply that my application now has the ability to use xAuth. but I'm having problem that [401 error - Failed to validate oauth signature and token] when requesting access token. So I want to check that my application is supporting xauth or not, How can I check? In my application page in twitter, there is no change. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Pulling data from Twitter
hi lau. check out http://dev.twitter.com/doc - the methods that you need to call are all documented there. On Sun, Jul 4, 2010 at 2:12 PM, lauthiamkok lau.thiam...@googlemail.comwrote: Hi, I am new to Twitter API and only know that we can pull someone's Twitter feed from Twitter through RSS feed on that person's Twitter page/ profile. But, how can I pull more information of that person's Twitter page? For instance, 1. His/ Her followers. 2. Total of his/ her retweet items. You can take a look here for what I mean above, http://www.qapture.net/ There are a couple of interesting things I still cannot figure them out how they did this website, 1. If you compare the particular person's twitter feed on this website with that person's twitter page, some of the items are pull in qapture website, but some are not, so I think they must have select certain items of feed only - how do they do that?? 2. If you mouse over an item of feed on qapture website, you can see other information of that feed item, such as '9 hours ago', '6 tweet(s)', etc - how do you get that information from? Which area of Twitter API that I should look into to achieve the matters above...? Many thanks! Lau -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] modifying rate limits under serious load
hi everyone, as you all know, Twitter has been faced with considerable capacity problems in recent weeks. we have many efforts under way to expand capacity and more efficiently use the capacity we have. starting today, we're going to begin adjusting rate limits dynamically under load in order to maintain an awesome experience for as many users as possible. today, we're experimenting with moving rate limits for all clients to varying amounts during periods of high load. you might see rate limits change from the default of 350 calls / hour. you may even see different values as we monitor the effect these changes have on overall Twitter performance. this means that it's more important than ever for client applications to monitor their rate limits through the HTTP headers and account/rate_limit_status and adjust your client's behavior accordingly. we're happy to help you achieve that, and please reach out to us if you need that help (either through this mailing list, or through @twitterapi). we understand that this might cause some issues in some clients, and will certainly impact the amount of requests your users can make to Twitter. however, the entire ecosystem will be more performant and you will see fewer whales on write operations (like posting tweets). thank you everyone for your continued patience. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
-totally- the timeline on this is, i think (and i'll check to be sure), sometime like 6-8 weeks. On Wed, Jun 9, 2010 at 1:45 AM, Rich rhyl...@gmail.com wrote: Please make sure the timeline for this is LONGER than 2 weeks please, some of us have to code this and then wait at least a week to get through Apple's approval system. This is especially important when it comes to detecting images, etc. Richard On Jun 9, 4:27 am, Raffi Krikorian ra...@twitter.com wrote: yeah - its definitely case that counting characters will become a bit more subtle. i hope that we can provide a really good and easy way to help you all out. at the very least we are going to update documentation, but i know we can do better than that. On Tue, Jun 8, 2010 at 8:17 PM, Andy Matsubara andymatsub...@gmail.com wrote: Raffi wrote: related to this: the way the Twitter API counts characters is going to change ever so slightly. our 140 characters is now going to be defined as 140 characters after link wrapping. t.co links are of a predictable length -- they will always be 20 characters. after we make this live, it will be feasible to send in the text for a status that is greater than 140 characters. the rule is after the link wrapping, the text transforms to 140 characters or fewer. we'll be using the same logic that is in twitter-text-rb to figure out what is a URL. I guess this change will make frontend text handling more difficult. Counting characters in a text box must figure out what is a URL. I hope Twitter will publish JavaScript library for realtime character counts. I also want APIs to make shortened URL. Andy Matsubara -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] link wrapping on the API
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://bit.ly/twttldmemail.
with that feature, we're trying to protect users against phishing and other
malicious attacks. the way that we're doing this is that any URL that comes
through in a DM gets currently wrapped with a twt.tl URL -- if the URL turns
out to be malicious, Twitter can simply shut it down, and whoever follows
that link will be presented with a page that warns them of potentially
malicious content. in a few weeks, we're going to start slowly enabling this
throughout the API for all statuses as well, but instead of twt.tl, we will
be using t.co.
practically, any tweet that is sent through statuses/update that has a link
on it will have the link automatically converted to a t.co link on its way
through the Twitter platform. if you fetch any tweet created after this
change goes live, then its text field will have all its links automatically
wrapped with t.co links. when a user clicks on that link, Twitter will
redirect them to the original URL after first confirming with our database
that that URL is not malicious. on top of the end-user benefit, we hope to
eventually provide all developers with aggregate usage data around your
applications such as the number of clicks people make on URLs you display
(it will, of course, be in aggregate and not identifiable manner).
additionally, we want to be able to build services and APIs that can make
algorithmic recommendations to users based on the content they are
consuming. gathering the data from t.co will help make these possible.
our current plan is that no user will see a t.co URL on twitter.com but we
still have some details to work through. the links will still be displayed
as they were sent in, but the target of the link will be the t.co link
instead. and, we want to provide the same ability to display original links
to developers. we're going to use the entities attribute to make this
possible.
let's say i send out the following tweet: you have to check out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://t.co/s9gfk2d4!;,
...
user : {
screen_name : raffi,
...
},
...
entities : {
urls : [
{
url : http://t.co/s9gfk2d4;,
display_url : http://dev.twitter.com;,
indices : [23, 43]
}
],
...
},
...
}
two things to note: the text of the returned status object doesn't have the
original URL and instead it has a t.co URL, and the entities block now has a
display_url attribute associated with it. what we're hoping is that with
this data, it should be relatively easy to create a UI where you replace the
http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
this means the user would not see the t.co link, but we all can still
provide the protection and gather data from the wrapped link. for the
applications that don't choose to update, the t.co link will be shown (and
the goal to protect users will be met). i just want to emphasize -- we
really do hope that you all render the original URL, but please send the
user through the t.co link. if you do choose to prefetch all the URLs on a
timeline, then, when a user actually clicks on one of the links, please
still send him or her through t.co. We will be updating the TOS to require
you to check t.co and register the click.
related to this: the way the Twitter API counts characters is going to
change ever so slightly. our 140 characters is now going to be defined as
140 characters after link wrapping. t.co links are of a predictable length
-- they will always be 20 characters. after we make this live, it will be
feasible to send in the text for a status that is greater than 140
characters. the rule is after the link wrapping, the text transforms to 140
characters or fewer. we'll be using the same logic that is in
twitter-text-rb to figure out what is a URL.
look for an update to dev.twitter.com where we'll have a best practices
document on how to use these t.co links.
what's the timeline? soon we'll enable this on @twitterapi, @rsarver,
@raffi, and a few other test accounts so you all have live data to play
with. on the timescale of weeks (to potentially a month or two), we'll roll
this out to everybody.
of course, if there are any questions, just feel free to direct them to
@twitterapi!
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
*1)* Will the redirect from t.co - domain.com be a 301 Moved Permanently
or a 302 Found response?
301!
*2)* Will the t.co URL redirect point to the URL in the original tweet, or
will it point to the ultimate resolved URL?
I.e., if I post Check out my site at http://bit.ly/abcd; where
bit.ly/abcd redirects to domain.com, and the resultant tweet becomes
Check out my site at http://t.co/abcd;, will the t.co URL redirect like
this:
a) t.co/abcd - domain.com
Or like this:
b) t.co/abcd - bit.ly/abcd - domain.com
we're not modifying or tampering with URLs - if you send us a bit.ly link,
we will wrap that bit.ly link. analytics will still work, etc.
*3)* In the above scenario, will the 'display_url' contain '
http://bit.ly/abcd' or 'http://domain.com'?
bit.ly!
*4)* Why redirect all URLs, btw? Why not just redirect the malicious
ones?
in the case of malicious URLs, you sometimes don't know it at the time of
tweet creation. or the URL may eventually become malicious. this allows us
to do shutdown after tweet creation.
Thanks!
that's what i'm here for :P
-DeWitt
On Tue, Jun 8, 2010 at 3:57 PM, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://bit.ly/twttldmemail.
with that feature, we're trying to protect users against phishing and other
malicious attacks. the way that we're doing this is that any URL that comes
through in a DM gets currently wrapped with a twt.tl URL -- if the URL
turns out to be malicious, Twitter can simply shut it down, and whoever
follows that link will be presented with a page that warns them of
potentially malicious content. in a few weeks, we're going to start slowly
enabling this throughout the API for all statuses as well, but instead of
twt.tl, we will be using t.co.
practically, any tweet that is sent through statuses/update that has a
link on it will have the link automatically converted to a t.co link on
its way through the Twitter platform. if you fetch any tweet created after
this change goes live, then its text field will have all its links
automatically wrapped with t.co links. when a user clicks on that link,
Twitter will redirect them to the original URL after first confirming with
our database that that URL is not malicious. on top of the end-user
benefit, we hope to eventually provide all developers with aggregate usage
data around your applications such as the number of clicks people make on
URLs you display (it will, of course, be in aggregate and not identifiable
manner). additionally, we want to be able to build services and APIs that
can make algorithmic recommendations to users based on the content they are
consuming. gathering the data from t.co will help make these possible.
our current plan is that no user will see a t.co URL on twitter.com but
we still have some details to work through. the links will still be
displayed as they were sent in, but the target of the link will be the
t.co link instead. and, we want to provide the same ability to display
original links to developers. we're going to use the entities attribute to
make this possible.
let's say i send out the following tweet: you have to check out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://t.co/s9gfk2d4!;,
...
user : {
screen_name : raffi,
...
},
...
entities : {
urls : [
{
url : http://t.co/s9gfk2d4;,
display_url : http://dev.twitter.com;,
indices : [23, 43]
}
],
...
},
...
}
two things to note: the text of the returned status object doesn't have
the original URL and instead it has a t.co URL, and the entities block
now has a display_url attribute associated with it. what we're hoping is
that with this data, it should be relatively easy to create a UI where you
replace the http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
this means the user would not see the t.co link, but we all can still
provide the protection and gather data from the wrapped link. for the
applications that don't choose to update, the t.co link will be shown
(and the goal to protect users will be met). i just want to emphasize -- we
really do hope that you all render the original URL, but please send the
user through the t.co link. if you do choose to prefetch all the URLs
on a timeline, then, when a user actually clicks on one of the links, please
still send him or her through t.co. We will be updating the TOS to
require you to check t.co and register the click.
related to this: the way the Twitter API counts characters is going to
change ever so slightly. our 140 characters is now going to be defined as
140 characters after link wrapping. t.co links are of a predictable
length -- they will always be 20 characters
Re: [twitter-dev] Re: link wrapping on the API
How will this affect links for third party services that clients
handle natively, such as Twitpic (and obviously TwitLonger, which
already has shorter dedicated short urls for its posts)?
that's why we are providing all the data back out in the API. while the
tweet itself may have t.co, we do include, in the entities, the original
URL. our hope, honestly, is that final users never have to see t.co -- we
want to provide enough data back to developers so they can create URLs that
look like
a href=http://t.co/blahblah;http://mycoolsite.com/a
all those URLs should still show through.
What about links through bit.ly etc? Will I still be able to see the
analytics that they provide for my links? If so, does that mean there
will be at least two levels of redirection from the ultimate
destination?
yes - we won't be touching the original URL. all analytics that users want
to see on bit.ly will still be there. this is what we do on URLs in DMs
right now.
On Jun 8, 11:57 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://bit.ly/twttldmemail.
with that feature, we're trying to protect users against phishing and
other
malicious attacks. the way that we're doing this is that any URL that
comes
through in a DM gets currently wrapped with a twt.tl URL -- if the URL
turns
out to be malicious, Twitter can simply shut it down, and whoever follows
that link will be presented with a page that warns them of potentially
malicious content. in a few weeks, we're going to start slowly enabling
this
throughout the API for all statuses as well, but instead of twt.tl, we
will
be using t.co.
practically, any tweet that is sent through statuses/update that has a
link
on it will have the link automatically converted to a t.co link on its
way
through the Twitter platform. if you fetch any tweet created after this
change goes live, then its text field will have all its links
automatically
wrapped with t.co links. when a user clicks on that link, Twitter will
redirect them to the original URL after first confirming with our
database
that that URL is not malicious. on top of the end-user benefit, we hope
to
eventually provide all developers with aggregate usage data around your
applications such as the number of clicks people make on URLs you display
(it will, of course, be in aggregate and not identifiable manner).
additionally, we want to be able to build services and APIs that can make
algorithmic recommendations to users based on the content they are
consuming. gathering the data from t.co will help make these possible.
our current plan is that no user will see a t.co URL on twitter.com but
we
still have some details to work through. the links will still be
displayed
as they were sent in, but the target of the link will be the t.co link
instead. and, we want to provide the same ability to display original
links
to developers. we're going to use the entities attribute to make this
possible.
let's say i send out the following tweet: you have to check outhttp://
dev.twitter.com!
a returned (and truncated) status object may look like:
{
text : you have to check outhttp://t.co/s9gfk2d4!;,
...
user : {
screen_name : raffi,
...
},
...
entities : {
urls : [
{
url : http://t.co/s9gfk2d4;,
display_url : http://dev.twitter.com;,
indices : [23, 43]
}
],
...
},
...
}
two things to note: the text of the returned status object doesn't have
the
original URL and instead it has a t.co URL, and the entities block now
has a
display_url attribute associated with it. what we're hoping is that with
this data, it should be relatively easy to create a UI where you replace
thehttp://t.co/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
this means the user would not see the t.co link, but we all can still
provide the protection and gather data from the wrapped link. for the
applications that don't choose to update, the t.co link will be shown
(and
the goal to protect users will be met). i just want to emphasize -- we
really do hope that you all render the original URL, but please send the
user through the t.co link. if you do choose to prefetch all the URLs
on a
timeline, then, when a user actually clicks on one of the links, please
still send him or her through t.co. We will be updating the TOS to
require
you to check t.co and register the click.
related to this: the way the Twitter API counts characters is going to
change ever so slightly. our 140 characters is now going to be defined as
140 characters after link wrapping. t.co links are of a predictable
length
-- they will always be 20 characters. after we make this live, it will be
feasible to send
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
that would be an awesome service! On Tue, Jun 8, 2010 at 4:50 PM, John Barratt djo...@gmail.com wrote: Hi Raffi, On 9/06/10 8:57 AM, Raffi Krikorian wrote: url : http://t.co/s9gfk2d4;, display_url : http://dev.twitter.com;, indices : [23, 43] Any chance of getting the title of the resolved URL added in here too if available? Then we could display a link like : a title=Twitter Dev href=http://t.co/s9gfk2d4; http://dev.twitter.com /a or : a title=http://dev.twitter.com; href=http://t.co/s9gfk2d4; Twitter Dev /a This would give even more context to users, without having to follow the redirect path, load and parse the page to extract it as well. Thanks, JB. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
its true, and we understand that.
just to correct my previous post, however -- t.co links are 19 characters.
On Tue, Jun 8, 2010 at 4:53 PM, Dewald Pretorius dpr...@gmail.com wrote:
This is not unique to me. This will be problematic for anyone who uses
a shortening service that shortens URLs to less than 20 characters.
In these cases, you are basically adding characters to the submitted
text, and then rejecting the submitted text as being too long.
On Jun 8, 8:33 pm, Dewald Pretorius dpr...@gmail.com wrote:
Raffi,
I'm fine with everything up to the new 140 character count.
If you count the characters *after* link wrapping, you are seriously
going to mess up my system. My short URLs are currently 18 characters
long, and they will be 18 long for quite some time to come. After that
they will be 19 for a very long time to come.
If you implement this change, a ton, and I mean a *huge* number of my
system's updates are going to be rejected for being over 140
characters.
On Jun 8, 7:57 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://bit.ly/twttldmemail.
with that feature, we're trying to protect users against phishing and
other
malicious attacks. the way that we're doing this is that any URL that
comes
through in a DM gets currently wrapped with a twt.tl URL -- if the URL
turns
out to be malicious, Twitter can simply shut it down, and whoever
follows
that link will be presented with a page that warns them of potentially
malicious content. in a few weeks, we're going to start slowly enabling
this
throughout the API for all statuses as well, but instead of twt.tl, we
will
be using t.co.
practically, any tweet that is sent through statuses/update that has a
link
on it will have the link automatically converted to a t.co link on its
way
through the Twitter platform. if you fetch any tweet created after this
change goes live, then its text field will have all its links
automatically
wrapped with t.co links. when a user clicks on that link, Twitter will
redirect them to the original URL after first confirming with our
database
that that URL is not malicious. on top of the end-user benefit, we
hope to
eventually provide all developers with aggregate usage data around your
applications such as the number of clicks people make on URLs you
display
(it will, of course, be in aggregate and not identifiable manner).
additionally, we want to be able to build services and APIs that can
make
algorithmic recommendations to users based on the content they are
consuming. gathering the data from t.co will help make these possible.
our current plan is that no user will see a t.co URL on twitter.combut we
still have some details to work through. the links will still be
displayed
as they were sent in, but the target of the link will be the t.co link
instead. and, we want to provide the same ability to display original
links
to developers. we're going to use the entities attribute to make this
possible.
let's say i send out the following tweet: you have to check outhttp://
dev.twitter.com!
a returned (and truncated) status object may look like:
{
text : you have to check outhttp://t.co/s9gfk2d4!;,
...
user : {
screen_name : raffi,
...
},
...
entities : {
urls : [
{
url : http://t.co/s9gfk2d4;,
display_url : http://dev.twitter.com;,
indices : [23, 43]
}
],
...
},
...
}
two things to note: the text of the returned status object doesn't have
the
original URL and instead it has a t.co URL, and the entities block now
has a
display_url attribute associated with it. what we're hoping is that
with
this data, it should be relatively easy to create a UI where you
replace thehttp://t.co/s9gfk2d4inthe text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
this means the user would not see the t.co link, but we all can still
provide the protection and gather data from the wrapped link. for the
applications that don't choose to update, the t.co link will be shown
(and
the goal to protect users will be met). i just want to emphasize -- we
really do hope that you all render the original URL, but please send
the
user through the t.co link. if you do choose to prefetch all the
URLs on a
timeline, then, when a user actually clicks on one of the links, please
still send him or her through t.co. We will be updating the TOS to
require
you to check t.co and register the click.
related to this: the way the Twitter API counts characters is going to
change ever so slightly. our 140 characters is now going to be defined
as
140 characters after link wrapping. t.co links are of a predictable
Re: [twitter-dev] Re: link wrapping on the API
our hope is to eventually provide this analytics. On Tue, Jun 8, 2010 at 7:14 PM, Sami sami.ben.romdh...@gmail.com wrote: I don't see how this feature could impact user privacy more than what it is right now. Today Twitter stores all links for all users and they can spy on them and the t.co shortner is not changing that :) My question is, will developers have access to analytics from t.co through API? Thanks -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of varying length.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
i guess i'm confused on this as well? isn't that what t.co does?
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://bit.ly/twttldmemail.
with that feature, we're trying to protect users against phishing and
other
malicious attacks. the way that we're doing this is that any URL that
comes
through in a DM gets currently wrapped with a twt.tl URL -- if the URL
turns
out to be malicious, Twitter can simply shut it down, and whoever follows
that link will be presented with a page that warns them of potentially
malicious content. in a few weeks, we're going to start slowly enabling
this
throughout the API for all statuses as well, but instead of twt.tl, we
will
be using t.co.
practically, any tweet that is sent through statuses/update that has a
link
on it will have the link automatically converted to a t.co link on its
way
through the Twitter platform. if you fetch any tweet created after this
change goes live, then its text field will have all its links
automatically
wrapped with t.co links. when a user clicks on that link, Twitter will
redirect them to the original URL after first confirming with our
database
that that URL is not malicious. on top of the end-user benefit, we hope
to
eventually provide all developers with aggregate usage data around your
applications such as the number of clicks people make on URLs you display
(it will, of course, be in aggregate and not identifiable manner).
additionally, we want to be able to build services and APIs that can make
algorithmic recommendations to users based on the content they are
consuming. gathering the data from t.co will help make these possible.
our current plan is that no user will see a t.co URL on twitter.com but
we
still have some details to work through. the links will still be
displayed
as they were sent in, but the target of the link will be the t.co link
instead. and, we want to provide the same ability to display original
links
to developers. we're going to use the entities attribute to make this
possible.
let's say i send out the following tweet: you have to check outhttp://
dev.twitter.com!
a returned (and truncated) status object may look like:
{
text : you have to check outhttp://t.co/s9gfk2d4!;,
...
user : {
screen_name : raffi,
...
},
...
entities : {
urls : [
{
url : http://t.co/s9gfk2d4;,
display_url : http://dev.twitter.com;,
indices : [23, 43]
}
],
...
},
...
}
two things to note: the text of the returned status object doesn't have
the
original URL and instead it has a t.co URL, and the entities block now
has a
display_url attribute associated with it. what we're hoping is that with
this data, it should be relatively easy to create a UI where you replace
thehttp://t.co/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
this means the user would not see the t.co link, but we all can still
provide the protection and gather data from the wrapped link. for the
applications that don't choose to update, the t.co link will be shown
(and
the goal to protect users will be met). i just want to emphasize -- we
really do hope that you all render the original URL, but please send the
user through the t.co link. if you do choose to prefetch all the URLs
on a
timeline, then, when a user actually clicks on one of the links, please
still send him or her through t.co. We will be updating the TOS to
require
you to check t.co and register the click.
related to this: the way the Twitter API counts characters is going to
change ever so slightly. our 140 characters is now going to be defined as
140 characters after link wrapping. t.co links are of a predictable
length
-- they will always be 20 characters. after we make this live, it will be
feasible to send in the text for a status that is greater than 140
characters. the rule is after the link
Re: [twitter-dev] Re: link wrapping on the API
Right now, Twitter can see all the links that users *post*, but they don't see which links users *click*. In order to implement this feature, Twitter has already built the framework that does all the hard work that applications need to protect users' privacy against (link-shortener) click-tracking. Twitter will be withholding that final URL from applications, preventing us (through the ToS) from implementing our own anti-click-tracking privacy measures. If, instead, they gave the final URL to the application and let the application use that URL, then applications could implement anti-click-tracking privacy measures with an even greater degree of privacy than they could by using a third-party service. hey brian - just wanted to point out - the Twitter will be withholding that final URL from applications is NOT true at all. we are providing, as part of the entities the original URL back to the developers. stated another way - we are giving all the data back and we are not withholding the data. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
yeah - its definitely case that counting characters will become a bit more subtle. i hope that we can provide a really good and easy way to help you all out. at the very least we are going to update documentation, but i know we can do better than that. On Tue, Jun 8, 2010 at 8:17 PM, Andy Matsubara andymatsub...@gmail.comwrote: Raffi wrote: related to this: the way the Twitter API counts characters is going to change ever so slightly. our 140 characters is now going to be defined as 140 characters after link wrapping. t.co links are of a predictable length -- they will always be 20 characters. after we make this live, it will be feasible to send in the text for a status that is greater than 140 characters. the rule is after the link wrapping, the text transforms to 140 characters or fewer. we'll be using the same logic that is in twitter-text-rb to figure out what is a URL. I guess this change will make frontend text handling more difficult. Counting characters in a text box must figure out what is a URL. I hope Twitter will publish JavaScript library for realtime character counts. I also want APIs to make shortened URL. Andy Matsubara -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Field constraints
Is there a reference that explains the field types and constraints of the data coming from the Twitter API? unfortunately, no - we don't have a centralized document listing all this (although, we probably should). Some things are a bit uncertain. For example, are user IDs 32bit or 64 bit integers? right now, there are less than 2^32 users, if that helps :P are there any other fields that are ambiguous? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] WebSockets protocol for streaming API
as a fallback - some people have had some success using http://github.com/r/twstreamer to get access to the stream from javascript (using flash as a bridge). usual caveats around production-izing streams apply. On Sat, May 15, 2010 at 5:38 AM, Cezar Sá Espinola ceza...@gmail.comwrote: Hey guys, Quick question, are there any plans on supporting WebSockets protocol for the Streaming API? That'd be awesome for browser based Twitter clients (i.e. Google Chrome extensions). Without this it'll be very difficult for this kind of client to lavarage benefit from the upcoming user streams. Thanks a lot for all your hard work, Cezar Sá Espinola @cezarsa -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Twitter returns different tweet ids.
how are you defining correct? ie - what are you comparing the ids against so as to lead you to think they are not correct? On Sat, May 15, 2010 at 2:25 PM, omergul123 omergul...@gmail.com wrote: Hello. when I call the statuses/home_timeline api method ro retrieve the tweets, the ids of the tweets that are returned are not correct. What could be the problem? All the data except the tweet id are returned correctly. I use the jmathai's twitter client: http://github.com/jmathai/twitter-async -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Leveraging the Twitter API and scraping out tweets to only include tweets with links
(this will become easier once we can roll out entities into the XML/JSON payload) On Fri, May 14, 2010 at 5:21 AM, Abraham Williams 4bra...@gmail.com wrote: You could just do a check to see if the status contains a http:// or https://. You might miss a few that don't include the protocol but it would be a pretty small amount. Abraham On Thu, May 13, 2010 at 15:15, Mrs. Tillman katlen.till...@gmail.comwrote: I am working on a project for a client and I am looking into using the Twitter API to feed in tweets from those users who opt-in to have their twitter feed brought in. One thing that I wanted to do to customize the feed is to only show those tweets that have a link included. Does anyone have any details on how to do this and whether it's pretty straight-forward to do? I am not a developer. Thanks! -- Abraham Williams | Developer for hire | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Read/Unread field?
Love the idea - pretty hard to do. Want to doit. Not sure when :p On Friday, May 14, 2010, Adam v0id@gmail.com wrote: I'm not sure if this has been asked before, but I was wondering about the inclusion of a read/unread field included with a status. So many applications conduct their own methods of knowing whether a tweet has been read, but it would be really good if this could be unified on Twitter. I'm not completely sure how it would work, maybe have a new API function to set the read/unread status, and tweets seen on Twitter.com itself would never set this status, only applications would use this function. This is just an idea though, what do you think? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
Besides, if this is the library used for web, you're not doing it right. :) For example, to mention URL parsing only, you don't check for valid domain names (e.g. www.test.failure is matched as URL), some characters are not recognized as part of a link (e.g. | in http://translate.google.com/?hl=en#auto|en|bonjour)... all we're trying to do is help people standardize on how they parse stuff. making sure you can represent what is a hash tag, a url, a username, etc., in the same way that twitter.com does it, can be difficult. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Read/Unread field?
annotations are immutable along with the tweet. you create annotations when you create a tweet, and they are stored with that tweet. On Fri, May 14, 2010 at 12:37 PM, janole s...@mobileways.de wrote: Wouldn't that be something for the upcoming Annotations? Ole -- Jan Ole Suhr s...@mobileways.de On Twitter: http://twitter.com/janole On 14 Mai, 12:45, Raffi Krikorian ra...@twitter.com wrote: Love the idea - pretty hard to do. Want to doit. Not sure when :p On Friday, May 14, 2010, Adam v0id@gmail.com wrote: I'm not sure if this has been asked before, but I was wondering about the inclusion of a read/unread field included with a status. So many applications conduct their own methods of knowing whether a tweet has been read, but it would be really good if this could be unified on Twitter. I'm not completely sure how it would work, maybe have a new API function to set the read/unread status, and tweets seen on Twitter.com itself would never set this status, only applications would use this function. This is just an idea though, what do you think? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
tweet text can potentially mention other users, lists, contain URLs, and
contain hashtags -- in fact, something like 50% of tweets contain at least
one of those. developers who want to understand the tweet text have to
parse the text to try to extract those entities (which can get really hard
and difficult when dealing with unicode characters) and then have to
potentially make another REST call to resolve that data. matt sanford
(@mzsanford) on our internationalization team released the twitter-text
library (http://github.com/mzsanford/twitter-text-rb) to help making parsing
easier and standardized (in fact, we use this library ourselves), but we on
the Platform team wondered if we could make this even easier for our
developers.
as part of our JSON and XML payloads, we are going to start supporting an
entities attribute that will contain this parsed and structured data.
you'll see it like so:
{
text : hey @raffi tell @noradio to check out http://dev.twitter.com#hot;,
...
entities : {
user_mentions : [
{
id : 8285392,
screen_name : raffi,
indices : [4, 9]
},
{
id : 3191321,
screen_name : noradio,
indices : [16, 23]
}
],
urls : [
{
url : http://dev.twitter.com;,
indices : [38, 64]
},
],
hashtags : [
{
text : #hot,
indices : [66, 69]
url : http://search.twitter.com/search?q=%23hot;
}
]
}
...
}
or like so
status
texthey @raffi tell @noradio to check out http://dev.twitter.com#hot/text
...
entities
user_mentions
user_mention start=4 end=9
id8285392/id
screen_nameraffi/screen_name
/user_mention
user_mention start=16 end=23
id3191321/id
screen_namenoradio/screen_name
/user_mention
/user_mentions
urls
url start=38 end=64
urlhttp://dev.twitter.com/url
/url
/urls
hashtags
hashtag start=66 end=69
text#hot/text
urlhttp://search.twitter.com/search?q=%23hot/url
/hashtag
/hashtags
/entities
...
/status
as shown above, we'll be parsing out all mentioned users, all lists, all
included URLs, and all hashtags. in the case of users, we'll provide you
their user ID, and for hashtags we'll provide you the query you can run
against the search API. and, for all of them, we'll also tell you at what
character count the entity starts and stops -- that should really take the
burden off you guys to parse the text properly.
this entities block will probably be extended later, and these entities are
just the start. have we missed anything? is there anything else you would
like to see? as always - just drop us a note, and look for these entities
to start slowly rolling out.
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] Re: parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
hey glenn.
i think something went wrong in the copy and paste -- there should have been
a space between the URL and the hashtag.
On Thu, May 13, 2010 at 11:02 PM, glenn gillen gl...@rubypond.com wrote:
Raffi,
This follows on nicely from the presentation at Warblecamp last week
discussing how difficult it is to do this right, and I think a
consistent approach across all clients (including twitter.com,
mobile.twitter, and 3rd party apps) should be priority number 1.
However looking at your example:
On May 13, 10:25 pm, Raffi Krikorian ra...@twitter.com wrote:
{
text : hey @raffi tell @noradio to check out
http://dev.twitter.com#hot;,
snip
{
url : http://dev.twitter.com;,
indices : [38, 64]
},
],
hashtags : [
{
text : #hot,
indices : [66, 69]
url : http://search.twitter.com/search?q=%23hot;
}
]
}
Without looking at how twitter.com would currently handle that
example, I would have expected the url to be http://dev.twitter.com/
#hot and for the tweet to contain no hashtag. If the hashtag always
takes precedence I'd have no way to link to the following without
using a URL shortener: http://oauth.net/core/1.0a/#anchor41
--
Glenn Gillen
http://glenngillen.com/
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
I have noticed that the API sometimes returns user ID’s that are out of sync with username. I think one case is where a Alice retweets Bob’s tweet, and then Bob changes his name to Charlie. When I try to reply to it, it doesn’t show up as “in reply to” to original tweet because the reply contains �...@bob” instead of �...@charlie”. It would actually get confusing because a new user could sign up as Bob and kind of “take over” Charlie’s old @mentions that contain �...@bob”. Is this change an attempt to address that, by fixing the screen_name-userid mapping at the time a tweet is created? i haven't thought about that. perhaps we could make that so. i need to investigate that. When we post tweets that include @mentions, can we include our own entities/user_mentions in our request body, so that Twitter can notify us if one of the mentioned screen names has a different userid than what we were expecting and/or one of the mentioned screen names is not a valid screen name anymore? That would be extremely helpful in dealing with this edge case—even if it was subject to some race conditions over a narrow period of time. again - great idea. can't guarantee anything, but let me think about it. probably not at the beginning, but this is a good idea. entities/user_mentions/screen_name and entities/user_mentions/text are redundant. I would rather just pick the text out of the tweet using original tweet text indexed by the indices property, to save bandwidth. in theory i like this. i'll probably send a follow up e-mail so that i can solicit other feedback. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] TweetDeck and xAuth
sorry - let me try to clarify, and if this is not clear on dev.twitter.com, please let us know so we can update the docs. native applications (desktop and mobile) can have permanent access to xAuth. web applications cannot. web applications can be granted temporary (approximately 7 days) access so that you can bulk convert your users from basic auth over to oauth. does that help? On Sun, May 9, 2010 at 4:51 PM, John Meyer john.l.me...@gmail.com wrote: On 5/9/2010 9:36 AM, Cameron Kaiser wrote: From what I've heard, xAuth is supposed to be temporary. Is TweetDeck just wording this wrong, or have they gained permanent access to xAuth? Actually, I am under the impression, and constructed TTYtter under this assumption, that desktop apps can have xAuth access on a longer term basis. Only web apps have time limits. See the notes on the (now obsoleted) xAuth apiwiki: The conversation I had on here with Raffi seemed to suggest xAuth was temporary in nature. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Why have I recieved a HTTP 601 Response.
hi! are you connecting through a proxy or some other intermediary? that failure doesn't seem like it came from the twitter stack. On Fri, May 7, 2010 at 10:10 AM, Asura hyuckmin.k...@gmail.com wrote: I have some Twitter login problem with my Polaris 6.2 Mobile Browser on handset device. I’ve been trying to figure it out. But I haven’t found out a problem, I really need you guys's answer for that. Currently, I use the IE user agent string for compatibility. I’ve attached some transaction log. Please let me know, if you guys need more information. I’m looking forward to your hopeful response. Thank you. - POST http://twitter.com/oauth/authorize HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/ vnd.ms-powerpoint, application/msword, */* Accept-Language: ko Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0); 800*480;POLARIS 6.100;em1.0;01057407732 Host: twitter.com Connection: Keep-Alive Referer: http://twitter.com/oauth/authorize?oauth_token=QQCGC4jstIj1LN73LZxuh2JhKEaeoifF7XfMSHjZRY Proxy-Authorization: Basic OTcyMjQ5NjEwNTp2enc= Cookie: guest_id=127181804004115551; original_referer=LQtHfb3aVLhzTQteZqBtMsK1SG1k6PabMrGGFzkb8SWvN4rcMar6PByaoAj77FrM0MzwLyUG00BPri2ivfClbpZqqFy5G5VDpU5n; auth_token=; _twitter_sess=BAh7CzoPY3JlYXRlZF9hdGwrCKpp52FRh4oAToOcmV0dXJuX3RvIl5odHRwOi8vv50AdHdpdHRlci5jb20vb2F1dGgvYXV0aG9yaXplP29hdXRoX3Rva2VuPVFRQ0dDD50ANGpzdElqMUxONzNMWnh1aDJKaEtFYWVvaWZGN1hmTVNIalpSWToRdHJhbnNff50AcHJvbXB0MDoMY3NyZl9pZCIlYmRiMzYzNWJjZWQ0MjYyZjc4ZDZmODViZTUyy50ANjhiZGM6B2lkIiUxYjg2NmE0OTliNjI0NDljNWUwMTc5Yjg1MWU1YmU1YiIKK50AZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsAA50ABjoKQHVzZWR7AAA53DD53D-- c2404da8c9fd8ee2a8738deeb9f7b77d49ee0c7d; __utmz=43838368.1271818261.2.2.utmcsr=browser.lgtelecom.com| utmccn=(referral)|utmcmd=referral|utmcct=/svc_twitter/fb/width/prg/ information_1.htm; __utma=43838368.114323.1271818047.1271818047.1271818261.2; __utmc=43838368; __utmv=43838368.langgAA0en; __utmb=43838368.4.10.1271818261 Content-Type: application/x-www-form-urlencoded Content-Length: 186 authenticity_token=8e936e0758e27e3bfd5dfba85e62ee418d045f6foauth_token=QQCGC4jstIj1LN73LZxuh2JhKEaeoifF7XfMSHjZRYsessionnBusername_or_emaillD=minbg717sessionnBpassworddD=m20062445 -- HTTP/1.1 601 Connect Fail Connection: close Content-Length: 55 HTMLBODYConnecting to WEB Server Fail/BODY/HTML -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: User tag inside users/show
i'm currently looking into this now. On Thu, May 6, 2010 at 4:51 AM, Rich rhyl...@gmail.com wrote: Yep looks like I spoke to soon, many of my users are still seeing this issue. I've actually handled it but Apple are now taking about a week to approve updates On May 6, 6:50 am, Raul raulr...@gmail.com wrote: We still see this issue on every request athttp://streamd.in, Also all other apps that use twitter4j are experiencing this issue. On May 5, 6:04 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: This should now be fixed, though it may take a little while for the cache to completely clear the labyrinth. Let us know if you're still having wide spread problems. Thanks! Taylor On Wed, May 5, 2010 at 2:27 PM, Rich rhyl...@gmail.com wrote: Cool, thanks Raffi, I was more concerned if it was intentional rather than a bug :) Of course we all get unintentional bugs from time to time On May 5, 10:21 pm, Raffi Krikorian ra...@twitter.com wrote: my stance on versioning is for when something has changed that breaks backwards compatibility. in this case, we haven't broken backwards compatibility, but a regression was introduced. regressions can get introduced in a variety of different ways, and across a variety of different properties unfortunately. software projects do their best to avoid them -- but its orthogonal to versioning either way - we're working on a fix. On Wed, May 5, 2010 at 2:11 PM, Orian Marx (@orian) or...@orianmarx.com wrote: Well, I'm not sure if Rich was referring to the output per se or rather that this bug was probably tied to the skip_user parameter that was just added to timelines... which one could argue is a candidate for versioning. On May 5, 5:02 pm, Raffi Krikorian ra...@twitter.com wrote: versioning has absolutely nothing to do with this - this is clearly a bug. On Wed, May 5, 2010 at 1:39 PM, Rich rhyl...@gmail.com wrote: Oh I'll add, I thought the point of a versioned API was that this sort of thing didn't happen? On May 5, 9:37 pm, Rich rhyl...@gmail.com wrote: I noticed today inside the user tags an extra user tag has appeared We now have user-status-user This is causing a crash on my app and number of engines I've tried. When did this get added and did I miss the notification? Many thanks Richard -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: User tag inside users/show
versioning has absolutely nothing to do with this - this is clearly a bug. On Wed, May 5, 2010 at 1:39 PM, Rich rhyl...@gmail.com wrote: Oh I'll add, I thought the point of a versioned API was that this sort of thing didn't happen? On May 5, 9:37 pm, Rich rhyl...@gmail.com wrote: I noticed today inside the user tags an extra user tag has appeared We now have user-status-user This is causing a crash on my app and number of engines I've tried. When did this get added and did I miss the notification? Many thanks Richard -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: User tag inside users/show
my stance on versioning is for when something has changed that breaks backwards compatibility. in this case, we haven't broken backwards compatibility, but a regression was introduced. regressions can get introduced in a variety of different ways, and across a variety of different properties unfortunately. software projects do their best to avoid them -- but its orthogonal to versioning either way - we're working on a fix. On Wed, May 5, 2010 at 2:11 PM, Orian Marx (@orian) or...@orianmarx.comwrote: Well, I'm not sure if Rich was referring to the output per se or rather that this bug was probably tied to the skip_user parameter that was just added to timelines... which one could argue is a candidate for versioning. On May 5, 5:02 pm, Raffi Krikorian ra...@twitter.com wrote: versioning has absolutely nothing to do with this - this is clearly a bug. On Wed, May 5, 2010 at 1:39 PM, Rich rhyl...@gmail.com wrote: Oh I'll add, I thought the point of a versioned API was that this sort of thing didn't happen? On May 5, 9:37 pm, Rich rhyl...@gmail.com wrote: I noticed today inside the user tags an extra user tag has appeared We now have user-status-user This is causing a crash on my app and number of engines I've tried. When did this get added and did I miss the notification? Many thanks Richard -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Getting error 6 on geo/nearby_places
we're definitely working through the issues involved launching bigger data
sets - the data sets that we're publicly supporting right now is the united
states.
On Mon, May 3, 2010 at 10:05 AM, mynetx myne...@googlemail.com wrote:
Thanks Raffi, somehow my test coordinates were odd, I admit.
When will places all over Germany be available? Neither my home town
nor the next big city is listed, while a small village I had been
visiting recently is listed.
I also hate staring at Unable to locate you. Try again beneath the
tweetbox on twitter.com... while Google Maps finds me perfectly.
mynetx
On May 3, 6:46 am, Raffi Krikorian ra...@twitter.com wrote:
looking at the coordinate you are passing in (37.996163, -127.441406) --
that's in the pacific ocean. i don't think our rockdove database has
anything for that location
On Sun, May 2, 2010 at 12:58 PM, mynetx myne...@googlemail.com wrote:
I am getting this:
{errors:[{code:6,message:No data available for the given
coordinate}],query:{type:nearby_places,url:http://
api.twitter.com/1/geo/nearby_places.json?
query=lat=37.996163accuracy=0autocomplete=falselong=-127.441406granula
rity=neighborhood,params:
{coordinates:{coordinates:
[-127.441406,37.996163],type:Point},query:,accuracy:
0,autocomplete:false,granularity:neighborhood}}}
when trying to locate ANY pair of latitude and longitude, as well as
with locating my own IP address.
What am I doing wrong?
--
Raffi Krikorian
Twitter Platform Team http://twitter.com/raffi
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] Getting error 6 on geo/nearby_places
looking at the coordinate you are passing in (37.996163, -127.441406) --
that's in the pacific ocean. i don't think our rockdove database has
anything for that location
On Sun, May 2, 2010 at 12:58 PM, mynetx myne...@googlemail.com wrote:
I am getting this:
{errors:[{code:6,message:No data available for the given
coordinate}],query:{type:nearby_places,url:http://
api.twitter.com/1/geo/nearby_places.json?
query=lat=37.996163accuracy=0autocomplete=falselong=-127.441406granularity=neighborhood,params:
{coordinates:{coordinates:
[-127.441406,37.996163],type:Point},query:,accuracy:
0,autocomplete:false,granularity:neighborhood}}}
when trying to locate ANY pair of latitude and longitude, as well as
with locating my own IP address.
What am I doing wrong?
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] App Opportunity: OAuthcalypse
i'm confused - why not use an oauth php library if using php? On Fri, Apr 30, 2010 at 4:00 PM, Lil Peck lilp...@gmail.com wrote: If Twitter doesn't come up with a way for those of us who use PHP curl or ASP xhttp to automatically post status updates from our sites, then this could be a nice opportunity for someone to create a new web service to fill that gap. Code a service to which we post our updates that will in turn submit them to Twitter for us. Does anyone know of a service that does that now? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: About update limits
yeah - i was mistaken. i'm just a lowly engineer :P sutorius (the brian referenced on that e-mail, and he has posted in this forum before) knows best in this case. On Fri, Apr 30, 2010 at 4:34 PM, Chris White chris.chriswh...@gmail.comwrote: Hello Raffi, and yes - there is a whitelisting for status/updates -- please e-mail a...@twitter to ask for it. I don't have permissions so I can't post their name, but a friend of mine sent such a request and received this response: Thank you for writing in. Sorry for any confusion, but API whitelisting does not cover the statuses/update call, as this call is a POST method. All Twitter accounts are subject to the same 1000 tweets per day limit. We also do not have a specific limit status call for remaining tweets, but I will pass this along to our engineers as a feature request. I apologize for the inconvenience that this causes to you and your team. Thanks, Brian Seems to be conflicting with the previous statement, so I'm not sure what to make of it. Best Regards, Chris White -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Mobile OAuth Summary
hi. i'll follow up on this - do you have a notion of what browsers, what phones, etc. your users are coming from On Thu, Apr 29, 2010 at 1:49 AM, twittme_mobi nlupa...@googlemail.comwrote: Hello, I migrated my mobile web site to OAuth. Now, I have a lot of users complaining that the OAuth page of twitter is not mobile friendly.Some of them are getting just a blank screen or just cannot open it. My honest question is - this is being discussed many times but where are we with this? Are all those users really suppose to get such a bad user experience? Why would you need a javascript on a login page?Is it so hard to create such page just for mobile browsers? Is anybody handling this - I mean it is an obvious problem that we have for more than a year already. Any comments on this are highly appreciated. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Duplicate Statuses in Public Timeline
hi matt. are you using since_id on your public timeline calls? On Thu, Apr 29, 2010 at 4:54 AM, mattarnold1977 matt.arnold.1...@gmail.comwrote: This is the third time I've reported this issue in the last couple of weeks. I still have not received any word back from Twitter support regarding this issue. My server log is filling up with duplicate status errors coming from the public timeline. I'm waiting to hit the timeline until after the cache period, so it's not that. And, yes it's not just duplicate status ids I'm seeing, it's also duplicate statuses as well. Every time I hit the public timeline I compare the results against a months worth of data that I have saved. Is anyone else having this issue? -Matt -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] About update limits
the numbers are roughly broken up over the day. and the limit applies to an account. and yes - there is a whitelisting for status/updates -- please e-mail a...@twitter to ask for it. On Thu, Apr 29, 2010 at 5:26 AM, akaii chibiak...@gmail.com wrote: This is what the FAQ has to say about status update limits: Updates: 1,000 per day. The daily update limit is further broken down into smaller limits for semi-hourly intervals. Retweets are counted as updates. I'm a little unclear as to what exactly is meant by further broken down into smaller limits for semi-hourly intervals. Is the 1000 per day limit divided evenly between the 48 half hours each day (around 20 or so tweets per half an hour?). Also, I'm assuming this limit applies to each unique account? Is this limit absolutely fixed? Or is there some equivalent to whitelisting for status/update limits as well? Thanks... -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] API call to turn on location-based tweets?
unfortunately, no. you could send the user to the settings page, and there is also a mobile optimized page with just that checkbox on twitter.com that you could use too. On Thu, Apr 29, 2010 at 11:56 AM, sabernar sha...@gmail.com wrote: Is there an API call where I can turn on an auth'd user's location setting? I'm referring to the setting Add a location to your tweets. In my app, I want to give the users a choice on whether they can attach their location to their tweet, but it only works if the user has that setting in the profile checked. Since it's an opt-in, not many people have that setting on. Is there a way I can activate that setting for the user if they so choose? Thanks, S -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] countdown to OAuth / basic auth removal / OAuthcalypse
yes. On Wed, Apr 28, 2010 at 12:32 PM, Jason Wong ja...@kratedesign.com wrote: I guess to be more specific, will we still be able to use the Streaming API with basic auth after June 30th if there is no oAuth implementation for it? John Kalucki wrote: Eventually the Streaming API will be all oAuth as well, but on a different, yet to be determined, schedule. User Streams will launch with oAuth. The preview will switch over to oAuth soon. -John On Wed, Apr 28, 2010 at 9:05 AM, Jason Wong ja...@kratedesign.com wrote: Raffi, does the discontinuation of basic authorization on the API also effect the Streaming API or just the REST API? Thanks, Jason. Raffi Krikorian wrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a lot of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] To Raffi or Taylor re: xAuth
user streams, right now, uses basic auth. user streams are in a preliminary / experimental stage - we do not recommend (john would use stronger words) using them in production. we will be implementing oauth on the streaming api soon-ish. On Wed, Apr 28, 2010 at 4:10 PM, Aral Balkan aralbal...@gmail.com wrote: A question on this and how it relates to User Streams. Unless I'm mistaken (only took a cursory look/played around with User Streams), User Streams uses Basic Auth. So if my app uses both the User Streams API and the REST API, I have to both use xAuth for the REST calls and store the username/password to use for User Streams. Am I missing something? Thanks, Aral On Tue, Apr 27, 2010 at 11:48 PM, John Meyer john.l.me...@gmail.com wrote: On 4/27/2010 4:38 PM, Taylor Singletary wrote: The twitter screen name is less of a concern, yes John. But a Twitter username can take an email address also, which isn't information otherwise provided by the API and is personally identifiable and especially dangerous when stored in conjunction with a password. A screen name, in context with data we return to you falls under our rather liberal caching policies -- you get the screen name along with the user id as a response to a valid access token request. snip -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] How to transition from basic auth to oAuth for my website
hi! because you are only posting to a single twitter account, what you need to do is create a client application (you can do this from http://dev.twitter.com/apps/new, and then bring up your application http://dev.twitter.com/apps and click on my access token. great - you now have everything you need token-wise. now, you can use any variety of oauth libraries. once you've chosen your library, then just feed it the consumer token / consumer secret / access token / access secret and you should be set. On Wed, Apr 28, 2010 at 8:40 PM, ebae eric...@gmail.com wrote: I have a website. It posts status updates to a single twitter account automatically. I store user name and password in a configuration file. I tried using oAuth to do the same thing, but this does not work because 1. twitter asks for user name and password 2. my website will not be able to automatically fill out the user name and password fields. Can you PLEASE tell me how I can achieve this? I'm assuming all the things I could do with basic auth is also possible with oAuth. Thank you. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Schedule for API call rate increases with oAuth?
hi ron. i'm just seeing you respond to every message in this thread lambasting oauth, so i figured it may be time to say something. i suggest you read up on the history of oauth? there are two reasons, that i care about, that oauth is important: 1. *minimizing the exposure of user's usernames and passwords*: in the base case, no - i don't trust random applications to have access to user's passwords. this is similar to the argument i made in this blog post: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap. there are a few applications i trust more than i trust other apps: mail.app on my mac, for example, safari and chrome, for example. sure, its possible to attack those applications -- but, i believe, the probability of somebody managing an attack on those applications is significantly greater than the probability of an application, malicious or not, exposing a password. the password could be exposed for malicious means, or simply a bug. mail.app, safari, chrome, etc. have massive corporations who are very much incentivized to patch/update them if there is a security problem. random-twitter-app? not so much. (a different argument on this theme, however, is whether users care about this) 2. *providing differing levels of access*: twitter implements read and read/write as access profiles on applications. it is possible to give an application only read access to your account, which means that it cannot post a status update -- only read your timeline and such. this is not possible in a world where you are handing out your password. if a user's password is giving to a third party application, then all the permissions of a user is exposed. sure - i also have interests regarding visibility into the platform (if an application has a bug, we can trivially figure out which application it is; if a user is curious which app is reading my DMs we will be able to tell them, etc.). but i also really do care about the security of users. Some of you talk about an app as if it were a person. Sure, apps could be malicious, but that includes every app on your computer - doesn't it? Why should you assume some of the apps handling your credentials can be more trustworthy than others? Any app that is on your computer while you type your username/password can potentially obtain that information. And what about the app at the far end of the Internet that may be pretending to be Twitter's authorization page? Frankly, I think the whole argument about malicious apps is a little over the top for an OAuth discussion. Why would you believe that basic auth developers are required to store passwords in plain-text...? I'm a basic auth developer, and I have always stored username/passwords encrypted in a access protected keychain file. I do not know of a single developer of any platform that would be so irresponsible as to store username/passwords in plain text - well until now. :) Twitter's only interest in OAuth (like any other platform provider) is to control access to their platform at an application level, and to allow other platform providers access to their users' data. This altruistic nonsense about Twitter being more interested in your personal password protection than your bank, your online stock trading company, or the IRS, is just that - nonsense. There's nothing wrong with Twitter's decision to implement OAuth. I makes perfect sense. I'd do it, if I were in their shoes. Why are so many of you rushing to their defense with these manufactured alternative reasons for why they are implementing it? On Apr 27, 5:52 am, glenn gillen gl...@rubypond.com wrote: Anytime you enter your credentials, regardless of where, you open yourself to being snooped. I believe that is far less likely when communicating with YOUR app on YOUR computer, than it is via a browser over the open Internet to a 3rd party that may or may not be who you think it is... Supporting this option though Twitter is dependent on the security procedures of every 3rd party to maintain the integrity of an account. WithOAuthat least should an individual 3rd party have their security breached then access to just that 3rd party can be terminated. Also with basic auth developers are required to store passwords in plain-text (or at least in some retrievable form) and as someone else has already pointed out with the propensity for users to use the same password on many services this exposes them to undue risk from a breach of a 3rd party or via a malicious developer. I'd sleep much easier at night if I didn't know anybody else's password, I'm sure the Twitter team would prefer if only a user knew their own password too. -- Glennhttp://glenngillen.com/ -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform
Re: [twitter-dev] Re: Schedule for API call rate increases with oAuth?
I've implemented OAuth some time ago, with no real issues. For the environment Twitter is in, I think it makes perfect sense. My BS sensors went off at some of the comments I saw circulating as to what OAuth's principal benefits are. But if you'd rather not see any dissenting opinions expressed on this forum, I can happily keep my thoughts to myself. dissenting opinions are ALWAYS WELCOME. i just wanted to provide some of my opinion to the story. i think, like everything, there are shades of gray. On Apr 27, 11:29 am, Raffi Krikorian ra...@twitter.com wrote: hi ron. i'm just seeing you respond to every message in this thread lambasting oauth, so i figured it may be time to say something. i suggest you read up on the history of oauth? there are two reasons, that i care about, that oauth is important: 1. *minimizing the exposure of user's usernames and passwords*: in the base case, no - i don't trust random applications to have access to user's passwords. this is similar to the argument i made in this blog post: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap. there are a few applications i trust more than i trust other apps: mail.app on my mac, for example, safari and chrome, for example. sure, its possible to attack those applications -- but, i believe, the probability of somebody managing an attack on those applications is significantly greater than the probability of an application, malicious or not, exposing a password. the password could be exposed for malicious means, or simply a bug. mail.app, safari, chrome, etc. have massive corporations who are very much incentivized to patch/update them if there is a security problem. random-twitter-app? not so much. (a different argument on this theme, however, is whether users care about this) 2. *providing differing levels of access*: twitter implements read and read/write as access profiles on applications. it is possible to give an application only read access to your account, which means that it cannot post a status update -- only read your timeline and such. this is not possible in a world where you are handing out your password. if a user's password is giving to a third party application, then all the permissions of a user is exposed. sure - i also have interests regarding visibility into the platform (if an application has a bug, we can trivially figure out which application it is; if a user is curious which app is reading my DMs we will be able to tell them, etc.). but i also really do care about the security of users. Some of you talk about an app as if it were a person. Sure, apps could be malicious, but that includes every app on your computer - doesn't it? Why should you assume some of the apps handling your credentials can be more trustworthy than others? Any app that is on your computer while you type your username/password can potentially obtain that information. And what about the app at the far end of the Internet that may be pretending to be Twitter's authorization page? Frankly, I think the whole argument about malicious apps is a little over the top for an OAuth discussion. Why would you believe that basic auth developers are required to store passwords in plain-text...? I'm a basic auth developer, and I have always stored username/passwords encrypted in a access protected keychain file. I do not know of a single developer of any platform that would be so irresponsible as to store username/passwords in plain text - well until now. :) Twitter's only interest in OAuth (like any other platform provider) is to control access to their platform at an application level, and to allow other platform providers access to their users' data. This altruistic nonsense about Twitter being more interested in your personal password protection than your bank, your online stock trading company, or the IRS, is just that - nonsense. There's nothing wrong with Twitter's decision to implement OAuth. I makes perfect sense. I'd do it, if I were in their shoes. Why are so many of you rushing to their defense with these manufactured alternative reasons for why they are implementing it? On Apr 27, 5:52 am, glenn gillen gl...@rubypond.com wrote: Anytime you enter your credentials, regardless of where, you open yourself to being snooped. I believe that is far less likely when communicating with YOUR app on YOUR computer, than it is via a browser over the open Internet to a 3rd party that may or may not be who you think it is... Supporting this option though Twitter is dependent on the security procedures of every 3rd party to maintain the integrity of an account. WithOAuthat least should an individual 3rd party have their security
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
One solution, which I know won't win the popularity prize, is for Twitter to relax its XAuth restrictions and allow web apps to use full OAuth and/or XAuth, depending on what works best for them. In my case, I will still use full OAuth because it's so much better than dealing with Twitter credential issues. But, I will add a small link below the Twitter authorize button on my site that says something like, Can't get to Twitter.com? which then leads to a username- password entry form, and then triggers an XAuth authorization. unfortunately, this defeats the purpose of oauth :( http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
i don't know very much about textpattern, however, might @anywhere be a solution for this? On Mon, Apr 26, 2010 at 11:08 AM, monkeyninja andy1...@gmail.com wrote: Hi Raffi, Not sure if I am following this correctly or not, but basically I have been developing a plugin for Textpattern for a while that uses basic authorisation to update a Twitter feed based on the username/password set for the plugin. Does this change mean that the user would now be temporarily passed back to Twitter before they would be authorised? I am hoping this isn't the case as it would make the plugin somewhat useless to the people using it. On Apr 24, 4:40 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown . -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: local trends api trends/available not working
hi mark.
i just called the trends api manually myself (
http://api.twitter.com/1/trends/available.xml and
http://api.twitter.com/1/trends/2367105.xml) and both seemed to work.
On Mon, Apr 26, 2010 at 11:04 AM, Mark Pavlidis mark.pavli...@gmail.comwrote:
Hey Raffi,
I see the status update at
http://status.twitter.com/post/516695583/local-trends-disabled
that local trends are slowly being restored. I see it on the web, any
indication when it will return to the API?
Thx,
@mhp
On Apr 18, 8:49 am, Raffi Krikorian ra...@twitter.com wrote:
the error that we are returning is unfortunate, but --
http://status.twitter.com/post/516695583/local-trends-disabled-- local
trends have been temporarily disabled.
On Sat, Apr 17, 2010 at 10:52 PM, rakf1 kris...@gmail.com wrote:
local trends api trends/available is no longer working, it was
working fine until recently. I'm using this in my iPhone app
iTrends. Below is the API call and the response I'm getting.
http://api.twitter.com/1/trends/available.json
{request:/1/trends/available.json,error:Sorry, you do not have
access to this endpoint.}
I looked at the API documentation, it has not changed, it does not
require any authentication. Any help is appreciated.
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] xAuth Approval?
it should be on the order of days (hopefully less - depends on our backlog and our queue). On Mon, Apr 26, 2010 at 11:52 AM, Tony tony.ar...@gmail.com wrote: I recently submitted a request for xAuth approval for a mobile app. I was wondering if anyone knows roughly how long it takes for approval. Thanks! -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] xAuth Approval?
a bit unsure - we're still working out what the appropriate terms for xauth should be. we just wanted it out there ASAP because of basic auth removal. I recently submitted a request for xAuth approval for a mobile app. I was wondering if anyone knows roughly how long it takes for approval. Thanks! On a larger note, is xAuth always going to be something that requires pre-approval? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] xAuth Approval?
just to be clear - what xAuth is used for is to do a username/password exchange for an oauth access token / secret (for a given application). from then on out, that access token and secret is used to sign all requests in an oauth manner. On Mon, Apr 26, 2010 at 12:48 PM, John Meyer john.l.me...@gmail.com wrote: On 4/26/2010 1:30 PM, Raffi Krikorian wrote: a bit unsure - we're still working out what the appropriate terms for xauth should be. we just wanted it out there ASAP because of basic auth removal. Is there anything that you can do with xAuth that you can't do with oAuth? If not I would think the only possible additions would be don't store the password. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] status sent with the text follow x returns latest tweet from usertimeline
this is a list of all the commands that are supported - http://help.twitter.com/forums/59008/entries/14020-the-official-twitter-text-commands. all sms commands are also available in status/update. On Mon, Apr 26, 2010 at 12:51 PM, srikanth reddy srikanth.yara...@gmail.com wrote: Hi One of the users of my app has asked for this. I have made a quick test here http://dev.twitter.com/console for POST /1 statuses/update with 'status' param value as follow betavine. The response iam getting is the latest entry from my usertimeline.(and i now follow betavine because of this command) My app just displays the response text in recent tab results if the response status is 200.The same way you do it from web interface.Problem is this is not a recent tweet (months old) but appears in recent tab. Should the app check for the commands like these before sending? Or shouldn't the response be different? (as we have a different endpoint for this 'follow' command). If app has to check such commands where do i get info about all the possible commands. iam using https://api.twitter.com/1/statuses/update.json. Any comments? Thanks Srikanth -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Twitter Background Image Update
this is in ruby, but it at least shows how to do this using oauth http://gist.github.com/279650 On Mon, Apr 26, 2010 at 2:25 PM, NASIR MANDAL nasir@gmail.com wrote: Hi , Any one know how to update twitter background image, Please write me with curl or autho by using php -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] xAuth Approval?
precisely. On Mon, Apr 26, 2010 at 2:41 PM, John Meyer john.l.me...@gmail.com wrote: On 4/26/2010 2:15 PM, Raffi Krikorian wrote: just to be clear - what xAuth is used for is to do a username/password exchange for an oauth access token / secret (for a given application). from then on out, that access token and secret is used to sign all requests in an oauth manner. So in other words if I'm reading this right, it allows the user program to exchange a username/password combo for the access token and secret rather than a pin or a redirect from a website in the case of desktop/mobile and website apps. Nothing else; you can't delete the account, change the password, etc without the username/pass. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Increasing 502/503 errors on Search API
what are the units we're looking at? On Mon, Apr 26, 2010 at 2:52 PM, mikawhite mikawh...@me.com wrote: I've charted the Search API over a few months... http://tweetprobe.tumblr.com/post/551639110 I'm concerned, Raffi :) -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] xAuth Approval?
honestly, i wouldn't plan on it. the spirit of oAuth is that the user's credentials never even pass through a web application. On Mon, Apr 26, 2010 at 3:02 PM, John Meyer john.l.me...@gmail.com wrote: On 4/26/2010 3:46 PM, Raffi Krikorian wrote: precisely. So is it a possibility that general xAuth will be available before Basic goes the way of the dodo? I'm not saying it's easier than oAuth but it would at least let developers use their interface and swap in the xAuth rather than having to plan for a web browser. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] xAuth Approval?
let's step back. oAuth is the general framework that we want everybody to use. applications no longer have to store usernames and passwords, which is a good thing. normally, to get access tokens, applications send users through the oAuth workflow -- this means they bring up a webpage on twitter.com, enter username/password there, and then the oAuth tokens are handed back to the application. xAuth is a method for which to exchange usernames and passwords for those tokens, without send the user through the workflow. this is for two reasons: 1. mobile/desktop application authors have complained that it makes their UX fugly when they bring up a web browser (i'll hold my opinions on this); and 2. web applications that have been storing usernames and passwords need a method to bulk convert all their users over to oauth tokens. after that bulk conversion, web applications can send new users through the oAuth web workflow. does that clear things up? On Mon, Apr 26, 2010 at 3:46 PM, John Meyer john.l.me...@gmail.com wrote: On 4/26/2010 4:23 PM, Raffi Krikorian wrote: honestly, i wouldn't plan on it. the spirit of oAuth is that the user's credentials never even pass through a web application. Now I'm confused. Is xAuth going to be a method unto itself of authenticating for the long-term, or is this the way that you are trying to transition Basic users to oAuth through xAuth before Basic is shut down? If it's the latter, I don't know why you would even bother if oAuth is simpler than xAuth in the first place. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Schedule for API call rate increases with oAuth?
What's the latest schedule for increasing the allowed API call rate for oAuth users? That seems to have been lost in the shuffle. unclear - we're actively working with our infrastructure and operations teams on capacity planning specifically so we can increase the rate limits. Also, is there any advantage to xAuth over the desktop PIN oAuth scheme (for a desktop application)? I'm putting together a proposal and can't see any real advantage to it on the desktop, especially since I have the oAuth code done, thanks to Marc Mims' Net::Twitter. ;-) personally, i would -love it-, if everybody just used the oauth web workflow so that none of you even see a user's username/password. that would make the web more secure. i'm even soliciting suggestions on what we could do to make the web workflow better. i understand, however, that the PIN workflow can be off putting for some users. so, implementing oAuth instead of xAuth would make me happy - but i doubt that's a motivation for most developers. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Schedule for API call rate increases with oAuth?
What's the latest schedule for increasing the allowed API call rate for oAuth users? That seems to have been lost in the shuffle. unclear - we're actively working with our infrastructure and operations teams on capacity planning specifically so we can increase the rate limits. just to clarify, however - oauth calls on api.twitter.com get 350/hr, whereas basic auth calls get 150/hr. so, that's one increase already... -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] xAuth Approval?
xAuth is a method for which to exchange usernames and passwords for those tokens, without send the user through the workflow. this is for two reasons: 1. mobile/desktop application authors have complained that it makes their UX fugly when they bring up a web browser (i'll hold my opinions on this); and 2. web applications that have been storing usernames and passwords need a method to bulk convert all their users over to oauth tokens. and 3. Browserless environments. I'm pretty sure that was one of the initial motivators way back when the crud was flying. Yeah ... but I *like* having the browser involved. +1 ! -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: Is /users/show broken or is it just me?
this shouldn't happen - feel free to give a sample of the poison user IDs, and we'll investigate them. we already have one, and we'll look into more. On Sun, Apr 25, 2010 at 10:16 AM, Ryan Rosario uclamath...@gmail.comwrote: I've found that all of my 500 isses are related to poison users. For whatever reason, I can never get their followers. I retry on 500, so I end up with an infinite loop of 500s for these users. When 500s happen with other users, my program usually succeeds after 1 or 2 retries. The only way to resolve it is to kill my process, add the user to a blacklist, and start over. It's really frustrating. Ryan On Apr 25, 5:31 am, Dossy Shiobara do...@panoptic.com wrote: From my logged errors ... here's an example: http://api.twitter.com/1/users/show.xml?id=4583991 On 4/25/10 12:37 AM, Mark McBride wrote: Without more details this is going to be really hard to troubleshoot. Can you reliably reproduce this? What are the exact URIs you're calling that return 500s? What user are you using to make these calls? What authentication method? -- Dossy Shiobara | do...@panoptic.com |http://dossy.org/ Panoptic Computer Network |http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Image Tags in Tweets?!
yes - we do this on occasion. we've done this before during world AIDS day (if you had a hashtag of #red, then the tweet, on twitter.com, would turn red), and now for malaria we are putting a mosquito on the tweet. twitter.com is trying to drive people to understand and discover what's going on in the world. On Sat, Apr 24, 2010 at 9:42 PM, Jaanus jaa...@gmail.com wrote: A fine answer, but does not answer the question ;) looks like you guys are injecting custom images after some hashtags on the site? J On Apr 23, 10:20 pm, Raffi Krikorian ra...@twitter.com wrote: http://hope140.org/endmalaria On Fri, Apr 23, 2010 at 2:54 PM, John Meyer john.l.me...@gmail.com wrote: On 4/23/2010 3:42 PM, Jonathan Strauss wrote: The last few tweets from @twitter feature the #endmalaria hash tag. On some pages, likehttp://twitter.com/twitterand http://twitter.com/#search?q=%23endmalaria, the hash tag is followed by an image of a mosquito (http:// a1.twimg.com/a/1272044617/images/mosquito.gif) which is hyperlinked to a different page than the hash tag itself. Yet on other pages, like http://twitter.com/twitter/status/12719532503, and in the API (http:// api.twitter.com/1/statuses/show/12719532503.xml), the mosquito image doesn't appear at all. What gives? Is this some kind of annotations test or something totally different? Well I wouldn't expect that a mosquito image appear on a text xml file, but it appears on the twitter 12719532503 status it appears. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Twitter Source Stats gets some JSON output love
totally awesome. On Sat, Apr 24, 2010 at 10:54 PM, funkatron funkat...@gmail.com wrote: Some of you may be familiar with my Twitter Source Stats project: http://funkatron.com/tss/ I've recently added the ability to get the ranking data back as JSON. You can just add .json to the end of the URL, and it'll spit it out. For example: http://funkatron.com/tss/lasthour http://funkatron.com/tss/lasthour.json I have pushed most of this code to github, although the code for stats collection isn't there right now -- it's done on another site atm. I'll try to pull that together soon, as well as clean up a bunch of unused code and scripts that are in there now. http://github.com/funkatron/twitter-stats-tracker Hit me up on Twitter if you have q's; I don't check in here a lot. Enjoy! -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.comxmpp%3afunkat...@gmail.com -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
not at all. twitter.com is already setup completely for oauth echo. at this point, its just 3rd party providers, and end clients. the @twitterapi team is ready to help out any of those that need help. On Sat, Apr 24, 2010 at 9:28 PM, Jaanus jaa...@gmail.com wrote: Is there any kind of special involvement needed from you every time someone wants to do OAuth Echo? I thought I'll make my own server for my own app for some purpose. Judging by the spec you posted on your blog a while ago (http://mehack.com/oauth-echo-delegation-in-identity- verificatio), it does not look like some special Twitter involvement is needed, as long as I implement all that's needed in my app and server? J On Apr 24, 5:44 pm, Raffi Krikorian ra...@twitter.com wrote: hi tom! i will be sending more info about it - we've been working with yfrog, tweetphoto, and twitpic to get their services migrated - they are either finished or are nearly there. if there are others that you would like the @twitterapi team involved with to help them get migrated over as well, then feel free to drop me an e-mail asking me. On Sat, Apr 24, 2010 at 10:48 AM, Thomas Woolway tswool...@gmail.com wrote: Hi Raffi, Great that we've got a date for basic auth deprecation, but is there any news/timescales on OAuth Echo? We've got nine weeks and counting to get the spec, get the service providers to implement it, build it into clients and get our user-bases to upgrade if they want to be able to upload photos post June 30th. That's easier if you're web based, but not a huge amount of time if you are desktop or mobile based. Thanks, Tom On Sat, Apr 24, 2010 at 4:49 PM, Raffi Krikorian ra...@twitter.com wrote: there is a really good chance - now that oauth 2.0 has been submitted as a drafthttp://tools.ietf.org/html/draft-hammer-oauth2-00, we are going to spend some time catching up our oauth 2.0 implementation. at that point, we'll evaluate letting it loose. On Sat, Apr 24, 2010 at 8:44 AM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, that is super awesome. Thank you. Any chance that you will have OAuth 2.0 in production before then? On Apr 24, 12:40 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown . -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: [twitter-api-announce] countdown to OAuth / basic auth removal / OAuthcalypse
it will be a while longer before streaming is converted. we'll of course, keep you as updated as possible! On Sun, Apr 25, 2010 at 11:36 AM, Dima Brodsky ddbrod...@gmail.com wrote: Hey, What's the timeline like, if you know, for the streaming api? Thanks! ttyl Dima On Sat, Apr 24, 2010 at 8:40 AM, Raffi Krikorian ra...@twitter.comwrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Twitter API documentation and resources: http://apiwiki.twitter.com API updates via Twitter: http://twitter.com/twitterapi Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
hi craig.
have you gotten access to xAuth? applications are not, by default, given
access to xAuth - if you e-mail a...@twitter.com with
- your client token; and
- a description of your application
then we can grant it access.
On Sun, Apr 25, 2010 at 1:22 PM, Craig Hockenberry
craig.hockenbe...@gmail.com wrote:
Hi Raffi!
Is there a delay/verification after a new app is created? I just
created a new app and am seeing problems getting the OAuth token with
a xAuth HTTP request that looks like this:
xAuth consumer key = N3fq77IdBT4qfglbcb4njg, consumer secret =
REDACTED
xAuth URL = https://api.twitter.com/oauth/access_token
xAuth HTTP method = POST, shouldHandleCookies = NO, cachePolicy =
NSURLRequestReloadIgnoringCacheData
xAuth HTTP headers = {
Content-Length = 78;
Content-Type = application/x-www-form-urlencoded;
}
xAuth HTTP body =
x_auth_mode=client_authx_auth_username=REDACTEDx_auth_password=REDACTED
I get back a status code of 0 and a response of Failed to validate
oauth signature and token.
For an older application with different consumer information (key =
5CAYV1DR5uwhVRJDBrepw) but the same username and password), I get back
a code of 200 and an empty response.
If there is indeed a delay for this information to propagate, you need
to let people know...
-ch
On Apr 24, 8:40 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
you're going to be hearing a lot from me over the next 9 weeks. our plan
is
to turn off basic authorization on the API by june 30, 2010 -- developers
will have to switch over to OAuth by that time. between now and then,
there
will be a *lot* of information coming along with tips on how to use OAuth
Echo, xAuth, etc. we really want to make this transition as easy as we
can
for everybody.
as always, please feel free to reach out to this group, or to @twitterapi
directly. if you need help remembering the date -
http://bit.ly/twcountdown
.
--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] Search for certain users Twits yields no results
i'm confused - i just went to both URLs, and both work? On Sun, Apr 25, 2010 at 1:40 PM, guytom guy.to...@gmail.com wrote: For some reason: http://search.twitter.com/search?from=Lakers While http://search.twitter.com/search?from=Celtics Works well Ideas anyone? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
before this gets out of hand - i, personally, am very sensitive to these issues. i've been spending some brain power trying to come up with a solution. if people have suggestions, then please feel free to reach out to me personally and off list. On Sun, Apr 25, 2010 at 7:54 PM, Ron B rbther...@gmail.com wrote: China's policy didn't just recently change, Twitter's did. So it is Twitter telling us that we may not be able to support China and other firewall blocked countries any longer. It is, after all, within Twitter's power to continue to support Basic Auth. It is their conscious decision not to, despite the significant negative ramifications being brought to their attention. In an earlier comment from Twitter: twitter.com is trying to drive people to understand and discover what's going on in the world. No one in the world needs to understand and discover what's going on more than the people of these communist-block countries that otherwise see only what their governments allow them to see. It is unfortunate that Twitter plans to turn their back on them. Then again, what's a billion people here or there?... On Apr 25, 9:04 pm, Abraham Williams 4bra...@gmail.com wrote: It is not twitter telling you it is China. -- Little androids dreaming of Nexus Ones compiled this text. On Apr 25, 2010 6:53 PM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, We really need a resolution for this issue before Basic Auth is deprecated. It sounds as if Twitter is telling developers of web apps that they cannot provide service to Chinese users, and other users behind firewalls that block access to twitter.com. But that can't be right, can it? On Apr 25, 4:49 am, jaronbarends jaronbare...@gmail.com wrote: I moved my web based app from ba... This issue has discussed in this group before here: https://groups.google.com/group/twitter-development-talk/browse_threa... Being a frontend developer, I may have misunderstood the outcome of that discussion (I certain... -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Public Timeline - Duplicate Status IDs
hi matt. it seems like you are asking about two things here. 1. the status IDs on the public timeline have zeros on the end -- that's because we have a really simple algorithm picking statuses that go into the public_timeline 2. between subsequent calls to the public timeline, even after the caching period, you are seeing duplicate statuses. so, for #2, are you seeing new statuses also? On Sat, Apr 24, 2010 at 6:15 AM, mattarnold1977 matt.arnold.1...@gmail.comwrote: I posted this issue a couple of days ago when I noticed my logs reporting duplicate status IDs from the public timeline. I haven't heard back from Twitter support, so I wanted to post another message out there. Perhaps someone else is experiencing this issue. I checked and it looks like around 8:54 PM on 4-19-10 Twitter's status IDs from the public timeline started reporting differently. Typically status IDs look something like this 12475374318, but now they all have zeros at the end like this 1247538. I thought this had something to do with the upcoming change to the way status ids were being generated. But Taylor from Twitter support said that change hasn't been implemented yet. My log is filling up with duplicate ID messages, so I'm hoping that someone out there knows what is going on. Any help would be greatly appreciated. Regards, Matt -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] countdown to OAuth / basic auth removal / OAuthcalypse
hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown . -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
sorry! i was just reminded about a point of clarification - streaming API will still support basic auth. this note *only* pertains to the REST API. hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
there is a really good chance - now that oauth 2.0 has been submitted as a draft http://tools.ietf.org/html/draft-hammer-oauth2-00, we are going to spend some time catching up our oauth 2.0 implementation. at that point, we'll evaluate letting it loose. On Sat, Apr 24, 2010 at 8:44 AM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, that is super awesome. Thank you. Any chance that you will have OAuth 2.0 in production before then? On Apr 24, 12:40 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown . -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
hi tom! i will be sending more info about it - we've been working with yfrog, tweetphoto, and twitpic to get their services migrated - they are either finished or are nearly there. if there are others that you would like the @twitterapi team involved with to help them get migrated over as well, then feel free to drop me an e-mail asking me. On Sat, Apr 24, 2010 at 10:48 AM, Thomas Woolway tswool...@gmail.comwrote: Hi Raffi, Great that we've got a date for basic auth deprecation, but is there any news/timescales on OAuth Echo? We've got nine weeks and counting to get the spec, get the service providers to implement it, build it into clients and get our user-bases to upgrade if they want to be able to upload photos post June 30th. That's easier if you're web based, but not a huge amount of time if you are desktop or mobile based. Thanks, Tom On Sat, Apr 24, 2010 at 4:49 PM, Raffi Krikorian ra...@twitter.comwrote: there is a really good chance - now that oauth 2.0 has been submitted as a draft http://tools.ietf.org/html/draft-hammer-oauth2-00, we are going to spend some time catching up our oauth 2.0 implementation. at that point, we'll evaluate letting it loose. On Sat, Apr 24, 2010 at 8:44 AM, Dewald Pretorius dpr...@gmail.comwrote: Raffi, that is super awesome. Thank you. Any chance that you will have OAuth 2.0 in production before then? On Apr 24, 12:40 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. you're going to be hearing a lot from me over the next 9 weeks. our plan is to turn off basic authorization on the API by june 30, 2010 -- developers will have to switch over to OAuth by that time. between now and then, there will be a *lot* of information coming along with tips on how to use OAuth Echo, xAuth, etc. we really want to make this transition as easy as we can for everybody. as always, please feel free to reach out to this group, or to @twitterapi directly. if you need help remembering the date - http://bit.ly/twcountdown . -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
first three are taken care of, just let me know if you need help coordinating with the others On Sat, Apr 24, 2010 at 4:34 PM, John Meyer john.l.me...@gmail.com wrote: On 4/24/2010 5:05 PM, Raffi Krikorian wrote: if there any applications / service providers that you would like the @twitterapi team to talk to - let me know. or, have the application / service provider come to us. i really want to make this transition as easy as possible. I'll probably be contacting those services. Right now we have interfaces for: *TweetPhoto *TwitPic *yFrog *FileSocial *Twic.li After I get my butt in gear and get xAuth support I'll probably next work on encapsulating all of these services (currently TweetPhoto, TwitPic and FileSocial are part of the main class) so that changes can be more easily worked on. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Early look at Annotations
Not to be glib, but they are more than welcome to join in on the conversation in the community. We plan to let the community really drive this one. On Apr 19, 2010, at 8:06 PM, R_Macdonald roger.g.macdon...@gmail.com wrote: ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that Twitter intends to leave the annotation classification system to be determined by the market. http://bit.ly/csK8Od Although I appreciate that Twitter values keeping the annotation ecosystem open for innovation and adaptation, I hope the conversation on Linked Data metadata standards within Twitter annotations is just beginning. It could be an historic lost opportunity if the hard driving Twitter team doesn’t step back and consider soliciting the counsel of the W3 C, Sir TB-L, Nigel Shadbolt and others in the Linked Data community. After all, Metaweb's Freebase team is just 3 blocks away. -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Can a single app support oAuth and xAuth?
It is possible, but why are you using xauth? It seems, as you are in the browser already, that you should just use the oauth workflow as is? On Apr 19, 2010, at 9:14 PM, YCBM youcannotb...@gmail.com wrote: Hi All, Can you a single registered oAuth app on Twitter be granted access to xAuth as well? We have a Firefox addon that let's people tweet the page they're on. While we're upgrading our site to support oAuth, we don't want to leave our Firefox addon behind. Is it possible to be granted xAuth for authentication with it under the same app name? Would seem confusing to have 2 registered apps, 1 for oAuth and 1 for oAuth w/ xAuth permissions. Is this even possible? Best, Y -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Announcing Twurl: OAuth-enabled curl for the Twitter API
| +--+ % twurl alias h /1/statuses/home_timeline.xml You can then use h in place of the full path. % twurl h Paths that require additional options such as request parameters for example can be used with aliases the same as with full explicit paths, just as you might expect. % twurl alias tweet /1/statuses/update.xml % twurl tweet -d status=Aliases in twurl are convenient +---+ | Changing your default profile | +---+ The first time you authorize a client application to make requests on behalf of your account, twurl stores your access token information in its .twurlrc file. Subsequent requests will use this profile as the default profile. You can use the 'accounts' subcommand to see what client applications have been authorized for what user names: % twurl accounts noradio HQsAGcBm5MQT4n6j7qVJw hhC7Koy2zRsTZvQh1hVlSA (default) testiverse guT9RsJbNQgVe6AwoY9BA Notice that one of those consumer keys is marked as the default. To change the default use the 'set' subcommand, passing then either just the username, if it's unambiguous, or the username and consumer key pair if it isn't unambiguous: % twurl set default testiverse % twurl accounts noradio HQsAGcBm5MQT4n6j7qVJw hhC7Koy2zRsTZvQh1hVlSA testiverse guT9RsJbNQgVe6AwoY9BA (default) % twurl set default noradio HQsAGcBm5MQT4n6j7qVJw % twurl accounts noradio HQsAGcBm5MQT4n6j7qVJw (default) hhC7Koy2zRsTZvQh1hVlSA testiverse guT9RsJbNQgVe6AwoY9BA +--+ | Contributors | +--+ Marcel Molina mar...@twitter.com / @noradio Raffi Krikorian ra...@twitter.com / @raffi -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
