[twitter-dev] Promoted Tweets and the API?
I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: What's happening with Tweetie for Mac
Have to admit it is kinda scary to develop for twitter, but maybe when more plans are released we'll understand twitter's plan a bit better. I don't begrudge Tweetie for being acquired, good for them, i'm sure it was a nice deal for them. It's a very narrow tightrope twitter walks though with developers will be interested to see how it all unfolds. On Apr 12, 4:18 pm, TvvitterBug by Applgasm-Apps tvvitter...@gmail.com wrote: So if I got this right, Twitter is going to distribute both Tweetie for iPhone and Tweetie for Mac for free, thus competing with its developer community in the Twitter desktop and mobile client space with free products? And all those other desktop and mobile apps that helped put Twitter on the map, well they're just SOL? And somehow Twitter believes this move is going to encourage developers to continue to develop for a platform that will eventually compete against all but one of them with predatory free pricing? Sounds like you must be looking for developers from the Las Vegas School of Business, not business partners within a symbiotic ecosystem.On Mon, Apr 12, 2010 at 9:40 AM, Ryan Sarver rsar...@twitter.com wrote: One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Need a report app button, something isn't quite right with Oauth....
NO but twitter does shut down perfectly good apps all the time... it's very frustrating. On Mar 4, 11:11 pm, Dewald Pretorius dewaldpub...@gmail.com wrote: Why would you want Tweetie or TweetDeck reported and disabled because some users use it to post spammy tweets?? On Mar 4, 5:23 pm,TammyFennell tammykahnfenn...@gmail.com wrote: Hi, this istammyfrom MarketMeTweet... been speaking extensively with Brian Sutorius about this, but wanted to post it here too. Right now apps are going inactive that use OAUTH and sometimes it seems there's no rhyme or reason. there's no well written rules, nothing. Truth is it's going to get even harder to police so why not do it the way you deal with spammy twitter accounts? Just put a report app next the from app under the tweet. Let it be user policed. Much easier for you! If developers start getting their apps shut down willy nilly, people are going to stop developing for twitter, simple as that... Other idea is to do certified apps, and push the heck out of those Let me know if i can be of any help! -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Promoted Tweets and the API?
I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result
Re: [twitter-dev] Re: Promoted Tweets and the API?
the announcements are only slowly coming out -- there will be a lot more details over the next few days through Chirp. as we move forward, as always, we'll message out to the developer list as features get deployed onto the platform / API. On Tue, Apr 13, 2010 at 6:48 AM, Duane Roelands duane.roela...@gmail.comwrote: I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Promoted Tweets and the API?
Is promotion of tweets going to be part of the algorithm for defining popular tweets - in a twisted world where twitter says it's popular coz they've taken the cash to say it's popular? [sorry, that sounds like rigging charts or something... not quite how I meant it to sound] Awaiting further details. On 13 April 2010 14:48, Duane Roelands duane.roela...@gmail.com wrote: I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result
[twitter-dev] Re: Can an authorize URL pass through a parameter?
Raffi Krikorian replied to my question about pass-through parameters in the callback URL: i don't think this is possible in oauth 1.0a. i know oauth 2.0 has a state parameter (don't quote me on the name) that will allow clients to pass an opaque string to the server who will then pass it back. One of my co-workers came up with this: looking at the twitter docu on github http://github.com/abraham/twitteroauth/blob/master/DOCUMENTATIONhttp://github.com/abraham/twitteroauth/blob/master/DOCUMENTATION i see this: 4) You will now have a Twitter URL that you must send the user to. You can add parameters and they will return with the user in step 5. https://twitter.com/oauth/authenticate?oauth_token=xyz123https://twitter.com/oauth/authenticate?oauth_token=xyz123 https://twitter.com/oauth/authenticate?oauth_token=xyz123info=abc // info will return with user I haven't tried this yet, but it appears to be saying that the feature I want _is_ available. How should I interpret it?
Re: [twitter-dev] Re: Promoted Tweets and the API?
- Nigel Legg nigel.l...@gmail.com wrote: Is promotion of tweets going to be part of the algorithm for defining popular tweets - in a twisted world where twitter says it's popular coz they've taken the cash to say it's popular? [sorry, that sounds like rigging charts or something... not quite how I meant it to sound] Awaiting further details. On 13 April 2010 14:48, Duane Roelands duane.roela...@gmail.com wrote: I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result People - please please please - if you are not going to be at Chirp, please please please post all of your questions about this (and everything else) to the Google Moderator site, so we can be sure they get on the agenda! http://www.google.com/moderator/#16/e=5c0f -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Promoted Tweets and the API?
Don't be too hasty with that ad blocking code. 1) It sounds as if Twitter will share ad revenue with external apps. 2) It very well might be against (new) API TOS to use the API and block ads (I would do that if I were them). On Apr 13, 10:48 am, Duane Roelands duane.roela...@gmail.com wrote: I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result- Hide quoted text - - Show quoted text - -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Chirp is coming to San Francisco April 14 and 15
The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comand register. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Chirp is coming to San Francisco April 14 and 15
Mo, as Taylor said, just grab a Hack Day ticket and we'll see you there! On Tue, Apr 13, 2010 at 9:06 AM, Mo maur...@moluv.com wrote: The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comand register. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Chirp is coming to San Francisco April 14 and 15
Thanks for the responses guys, but the first day means more to me than the second day. I'll keep looking around. -Mo On Apr 13, 9:28 am, Ryan Sarver rsar...@twitter.com wrote: Mo, as Taylor said, just grab a Hack Day ticket and we'll see you there! On Tue, Apr 13, 2010 at 9:06 AM, Mo maur...@moluv.com wrote: The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comandregister. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Chirp on Justin.tv
I notice that the Chirp channel is set to a private channel. http://www.justin.tv/twitterchirp Is it going to be made public on Wednesday, or else, where do we get the Access Code? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] oAuth Echo - Questions on Best Practices
Ok, so I'm a bit out of the loop so I've been doing a lot of catching up on oAuth Echo starting with http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c2c4963061422f28/d0b5ddeac81ecd84. Scenario is large number of Twitter clients accessing media upload api for our site service along with end-users sharing via browser. I understand June 2010 is the cutoff for basic auth. Some sites may be provided with xAuth on a limited basis in regards to moving everybody off basic authentication, we originally envisioned this as a mechanism for developers to exchange all the username and passwords they have in their databases for OAuth tokens en masse. Still trying to wrap my head around oAuth Echo. From what I understand, delegation from a Twitter app like TweetDeck (for example) would pass its oAuth access tokens to our site to pass to Twitter. A few questions: - xAuth seems straight-forward if granted temporary access. I assume these tokens are the same as if the end-user went through the normal oAuth process in a browser? New users to the 3rd party web site would be using oAuth. - Typically if a user is sharing a media file through our site and they are NOT registered (no account in our system) and have never logged in using oAuth on our site, we create an account for them. Can we store the access tokens from an external app when we create their account? If so, would there be a conflict if an event occurs in which we post a status update on their behalf without the delegation in the header? Or is it a one-time use thing? - Once the user visits our site and logs into Twitter using oAuth, we'll store those tokens. Is it best practice to use those whenever the same user shares a media file through an external app or should the delegated tokens always be used? - Finally, while Twitter may be depreciating basic auth and everyone (if they haven't already) will be using oAuth, is there a plan for users who use 3rd party Twitter apps for mobile devices that HAVE NOT upgraded to the latest version yet? Although xAuth is geared towards desktop and mobile apps, there may be quite a few users who have not upgraded their app trying to either use it or share media with it through sites like ours. - I did notice that on this page http://apiwiki.twitter.com/Authentication, its confusing as to whether or not basic auth will be completely depreciated. If it will be, someone should update it as its misleading. Thanks in advance! Best, Y. -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Chirp on Justin.tv
For completeness sake, the URL below will host the video on the Chirp site: http://chirp.twitter.com/live.html http://chirp.twitter.com/live.htmlThanks, Doug On Tue, Apr 13, 2010 at 12:06 PM, Doug Williams d...@twitter.com wrote: Dewald, This will be public (no access code needed) for the event. Thanks, Doug On Tue, Apr 13, 2010 at 10:54 AM, Dewald Pretorius dpr...@gmail.comwrote: I notice that the Chirp channel is set to a private channel. http://www.justin.tv/twitterchirp Is it going to be made public on Wednesday, or else, where do we get the Access Code? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Chirp on Justin.tv
Just to check - if we're unable to watch the live stream I presume saved videos will be available afterwards? On Apr 13, 8:06 pm, Doug Williams d...@twitter.com wrote: Dewald, This will be public (no access code needed) for the event. Thanks, Doug On Tue, Apr 13, 2010 at 10:54 AM, Dewald Pretorius dpr...@gmail.com wrote: I notice that the Chirp channel is set to a private channel. http://www.justin.tv/twitterchirp Is it going to be made public on Wednesday, or else, where do we get the Access Code? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Promoted Tweets and the API?
At present, search is not on my radar as an API I want to use in development, but I am concerned about the implications for monitoring services based on the search API. On 13 April 2010 15:31, Dewald Pretorius dpr...@gmail.com wrote: Don't be too hasty with that ad blocking code. 1) It sounds as if Twitter will share ad revenue with external apps. 2) It very well might be against (new) API TOS to use the API and block ads (I would do that if I were them). On Apr 13, 10:48 am, Duane Roelands duane.roela...@gmail.com wrote: I'm curious about this myself. One of the first things end users are going to ask for is a way to block these ads from their timelines. Don't kid yourself; there's a reason why AdBlock is such a popular Firefox plugin. Secondary question: Is the first step towards paid Twitter accounts, where free users have to receive ads and paid users do not? Straight answers here would be appreciated. On 13 Apr, 05:28, Tim fabianh...@googlemail.com wrote: I've been looking around for information on how the new promoted tweets advertising feature will affect the API, and I've not really found anything. I gather that it's a two phase approach starting with search and then rolling out to timelines, but can anyone here clarify: (a) whether API responses will include promoted tweets, (b) whether these tweets will be identified as ads (c) whether third parties are 'obligated' to present them to users (d) whether there will be an API Terms of Use as a result- Hide quoted text - - Show quoted text - -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] API Weird
http://api.twitter.com/1/ This also works: http://api.twitter.com/raffi/ Wouldn't it make more sense to kick back 404s on the api subdomain?
Re: [twitter-dev] API Weird
http://api.twitter.com/1/ This also works: http://api.twitter.com/raffi/ Wouldn't it make more sense to kick back 404s on the api subdomain? uh. yes. will look into it. don't do that. :P -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Thoughts moving forward
Anyone else want to join in on this? Ryan wants to chat about specifics in the 10:15 am session of the Hack Day, so I agree with Abraham that it makes sense to try and meet some time on Day 1 to collect some thoughts. I'm sure we'll have a lot of new info to digest as well. On Apr 12, 4:31 pm, Abraham Williams 4bra...@gmail.com wrote: I'm looking forward to Chirp and the dialogs that will happen. The Coop session on the second day looks to be the best time to have a heart to heart between third-party developers and the platform team. I think it would be good to have the third-party developers meet before then have a discussion about what we want and what our priorities are. I'm not sure when the best time would be. During the afternoon break or at 9pm on the first day seem like good times. I also think it would be respectful of Twitter employees to not attend this gathering so developers can be frank and honest. There will be many other opportunities. Abraham -- Abraham Williams | Developer for hire |http://abrah.am PoseurTech Labs | Projects |http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: What's happening with Tweetie for Mac
This is certainly a risk we all face. However in my mind there are ways Twitter can do a better job in indicating where we should and should not concentrate effort. For example, there are things that Twitter has had in its V2 roadmap for years now, and some of us have decided to try and implement them on our own. If Twitter was willing to set even very rough priorities for things and very rough estimates (soon is not a rough estimate) that could go a long way in preventing us from wasting our time. Obviously they aren't going to tell us in advance of major new functionality, but I'm referring to functionality they have already indicated they would like to tackle at some future point On Apr 12, 3:23 pm, Jesse Stay jesses...@gmail.com wrote: Not at all - I've spent 3 years building features constantly replaced by Twitter (or killed due to Twitter changing the TOS). I've been there, and had plenty of my share of crankiness - I guess I'm used to it now, and I realize that's just a part of writing apps for the ecosystem (or any 3rd party ecosystem for that matter). The more Twitter can be transparent about things like this, the happier I am. I'm glad they're starting to open up on where they stand. I hope this continues. Jesse On Mon, Apr 12, 2010 at 11:12 AM, Isaiah Carew isa...@me.com wrote: sorry for being cranky, but i just spent a year building a tweetie competitor. you can't fault a guy for saying ouch while your knife is still sticking out of his back, right? isaiah http://twitter.com/isaiah On Apr 12, 2010, at 9:10 AM, Jesse Stay wrote: I think it's great that Twitter is finally being more transparent about all this. I could argue they need to be more transparent (where do they plan to go in the analytics and enterprise spaces?), but it's about time. They've finally drawn the line in the sand - now we need to adapt. Yes, it's frustrating, but then again, 90% of businesses fail - it's the risk all of us took. We either compete, or quit, and move on. I don't get all the complaints - this is nothing new. I've had half my features replaced by Twitter over the last few years (quite literally - just read my blog - I'm the chief complainer). By now I realize that's either part of life (note: it's the same on Facebook, too - there's no escaping it), or I change my focus to where Twitter is not my core and I instead use Twitter to strengthen my new core. That's where Twitter (and Fred Thompson) have made it clear they want us to go. Finally, some clarity. I'm appreciative of it, regardless of how frustrating it can be. Time for all of us to take this constructively and adapt. Just my $.02 FWIW... Jesse On Mon, Apr 12, 2010 at 9:54 AM, Isaiah Carew isa...@me.com wrote: Crystal clear. 1. You're decimating the client market on every platform but Windows. 2. You're killing any potential for innovation or investment. 3. You have no clear (public) plan for any innovation yourself. What marketing genius... Oh never mind. It's not worth the breath. Good luck with that. Anyone want a chirp ticket? isaiah http://twitter.com/isaiah On Apr 12, 2010, at 7:40 AM, Ryan Sarver wrote: One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan
Re: [twitter-dev] Does xAuth accept email addresses?
Hi George, xAuth does accept email addresses. Your POST body by definition needs to be URL-escaped, and when you generate your signature base string that means that you'll be URL encoding those URL-encoded values again. Example POST body: x_auth_mode=client_authx_auth_password=thisismypassx_auth_username=someonesemail% 40address.com Example base string: POSThttps%3A%2F%2Fapi.twitter.com %2Foauth%2Faccess_tokenoauth_consumer_key%3Dri8JxYK2ddwSV5xIUfNNvQ%26oauth_nonce%3DgATtgiuYofyPwzUS32vwWDBxf43Y4cWvJLZ1NhMrYfI%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1271195706%26oauth_version%3D1.0%26x_auth_mode%3Dclient_auth%26x_auth_password%3Dthisismypass%26x_auth_username%3Dsomeonesemail% 2540address.com Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Tue, Apr 13, 2010 at 2:30 PM, George McBay g...@funxed.com wrote: I'm converting a twitter client from basic auth to xauth and everything is working fine except I have been unable to generate an oAuth token using xauth if the user attempts to sign in with an email address instead of their Twitter username. Is a Twitter user's email address a valid value for an xAuth x_auth_username parameter? And if so, is there anything about the encoding that's odd? I've tried the various obvious forms of HTTP value escaping but with no luck so far. It would be really nice to see something like the access_token page's Example Signature Base String that uses an email address (if that is even supported?) successfully. Thanks in advance. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Basic Auth Deprecation
Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Basic Auth Deprecation
we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Basic Auth Deprecation
Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
we'll make sure to message it long before hand! On Tue, Apr 13, 2010 at 4:30 PM, Dewald Pretorius dpr...@gmail.com wrote: Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] New methods for pending follow requests
We've deployed two new methods for retrieving pending follow requests for protected users: * /friendships/incoming * /friendships/outgoing The incoming method returns a list of users who have pending requests to follow the authenticating user. The outgoing method returns a list of protected users for whom the authenticating user has pending follow requests. Both methods return 5000 user IDs per page. Cursors are provided in the unlikely event that you need to page through a list of more than 5000 pending follow requests. Full documentation is here: https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-incoming https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-outgoing Enjoy! -- Dana Contreras Twitter Platform Team http://twitter.com/DanaDanger
[twitter-dev] New rate limit headers for users/search
We've added a new set of HTTP response headers to users/search to document its secondary rate limit: * X-FeatureRateLimit-Limit * X-FeatureRateLimit-Remaining * X-FeatureRateLimit-Reset * X-FeatureRateLimit-Class Calls to users/search are rate limited by the standard REST API rate limit, as well as by a secondary rate limit that applies only to users/search (60 calls per hour). If either of these limits is exceeded, access to users/search is restricted until the limits reset. The new headers provide information about the secondary rate limit in the same way that the existing X-RateLimit headers document the standard REST API rate limit. Both sets of headers will be sent in response to calls to users/search. You can find more information about this update here: https://apiwiki.twitter.com/Rate-limiting -- Dana Contreras Twitter Platform Team http://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: New rate limit headers for users/search
Uhm... wait a second.. I distinctly remember you guys (Raffi, I think I'm looking at you) said that secondary rate limits were dropped completely. On Apr 13, 8:32 pm, Dana Contreras d...@twitter.com wrote: We've added a new set of HTTP response headers to users/search to document its secondary rate limit: * X-FeatureRateLimit-Limit * X-FeatureRateLimit-Remaining * X-FeatureRateLimit-Reset * X-FeatureRateLimit-Class Calls to users/search are rate limited by the standard REST API rate limit, as well as by a secondary rate limit that applies only to users/search (60 calls per hour). If either of these limits is exceeded, access to users/search is restricted until the limits reset. The new headers provide information about the secondary rate limit in the same way that the existing X-RateLimit headers document the standard REST API rate limit. Both sets of headers will be sent in response to calls to users/search. You can find more information about this update here:https://apiwiki.twitter.com/Rate-limiting -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: New rate limit headers for users/search
on bulk user show. On Tue, Apr 13, 2010 at 4:39 PM, Dewald Pretorius dpr...@gmail.com wrote: Uhm... wait a second.. I distinctly remember you guys (Raffi, I think I'm looking at you) said that secondary rate limits were dropped completely. On Apr 13, 8:32 pm, Dana Contreras d...@twitter.com wrote: We've added a new set of HTTP response headers to users/search to document its secondary rate limit: * X-FeatureRateLimit-Limit * X-FeatureRateLimit-Remaining * X-FeatureRateLimit-Reset * X-FeatureRateLimit-Class Calls to users/search are rate limited by the standard REST API rate limit, as well as by a secondary rate limit that applies only to users/search (60 calls per hour). If either of these limits is exceeded, access to users/search is restricted until the limits reset. The new headers provide information about the secondary rate limit in the same way that the existing X-RateLimit headers document the standard REST API rate limit. Both sets of headers will be sent in response to calls to users/search. You can find more information about this update here: https://apiwiki.twitter.com/Rate-limiting -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: New rate limit headers for users/search
Did I tell you that the dog chewed my dictionary yesterday? Search, show, it's now all so confusing. On Apr 13, 8:40 pm, Raffi Krikorian ra...@twitter.com wrote: on bulk user show. On Tue, Apr 13, 2010 at 4:39 PM, Dewald Pretorius dpr...@gmail.com wrote: Uhm... wait a second.. I distinctly remember you guys (Raffi, I think I'm looking at you) said that secondary rate limits were dropped completely. On Apr 13, 8:32 pm, Dana Contreras d...@twitter.com wrote: We've added a new set of HTTP response headers to users/search to document its secondary rate limit: * X-FeatureRateLimit-Limit * X-FeatureRateLimit-Remaining * X-FeatureRateLimit-Reset * X-FeatureRateLimit-Class Calls to users/search are rate limited by the standard REST API rate limit, as well as by a secondary rate limit that applies only to users/search (60 calls per hour). If either of these limits is exceeded, access to users/search is restricted until the limits reset. The new headers provide information about the secondary rate limit in the same way that the existing X-RateLimit headers document the standard REST API rate limit. Both sets of headers will be sent in response to calls to users/search. You can find more information about this update here: https://apiwiki.twitter.com/Rate-limiting -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi- Hide quoted text - - Show quoted text -
[twitter-dev] Re: New rate limit headers for users/search
great story :P On Apr 13, 4:42 pm, Dewald Pretorius dpr...@gmail.com wrote: Did I tell you that the dog chewed my dictionary yesterday? Search, show, it's now all so confusing. On Apr 13, 8:40 pm, Raffi Krikorian ra...@twitter.com wrote: on bulk user show. On Tue, Apr 13, 2010 at 4:39 PM, Dewald Pretorius dpr...@gmail.com wrote: Uhm... wait a second.. I distinctly remember you guys (Raffi, I think I'm looking at you) said that secondary rate limits were dropped completely. On Apr 13, 8:32 pm, Dana Contreras d...@twitter.com wrote: We've added a new set of HTTP response headers to users/search to document its secondary rate limit: * X-FeatureRateLimit-Limit * X-FeatureRateLimit-Remaining * X-FeatureRateLimit-Reset * X-FeatureRateLimit-Class Calls to users/search are rate limited by the standard REST API rate limit, as well as by a secondary rate limit that applies only to users/search (60 calls per hour). If either of these limits is exceeded, access to users/search is restricted until the limits reset. The new headers provide information about the secondary rate limit in the same way that the existing X-RateLimit headers document the standard REST API rate limit. Both sets of headers will be sent in response to calls to users/search. You can find more information about this update here: https://apiwiki.twitter.com/Rate-limiting -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi-Hide quoted text - - Show quoted text -
[twitter-dev] Re: Details on the Chirp Hack Day Showcase
Question about this question Where can we demo the project? Are you looking for a url or to meet up before the showcase? On Apr 9, 2:35 am, Nigel Legg nigel.l...@gmail.com wrote: I'd love to resent, but can't make it to Chirp. Maybe next year. On 9 April 2010 07:11, Doug Williams d...@twitter.com wrote: Hi all -- The Hack Day at Chirp is a remarkable opportunity for the Twitter Platform. It is the first time that the ecosystem and Twitter's extended team will meet under one roof. We are excited to collaborate at such a deep level; answering questions face-to-face while updating the Twitter team on the innovation ongoing in the ecosystem. It is cool to think that the Hack Day will represent the largest pool of ecosystem companies and projects in the same room. To celebrate, we are hosting a Showcase to demo several apps developed during the event in addition to nascent companies beginning to gain traction. Here are some of the ideas we will we will look for: * Commerce: tools for marketers, consumer analytics and consumer insights. * Engagement: platforms for social good and government, leveraging Twitter to drive engagement. * Consumption: tools that surface relevant content, vertical integrations, leveraging geotagged tweets, innovative mobile experiences, user discovery, and media curation. * Infrastructure: tools for developers, and application marketing and distribution. The Showcase will feature demos of select products and a panel to discuss the opportunities explored by these budding projects. The only rules: projects must be less than one years old, must have less than one million dollars in funding and someone must be at the Chirp Hack Day on April 15th to present. To apply to demo at the Hack Day Showcase, please apply here [1] by 3PM on April 15th, 2010. 1.http://bit.ly/chirpshowcase Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Some thoughts leading up to Chirp
Well said Dewald! You've captured exactly how I feel about this. On Apr 13, 12:07 am, Dewald Pretorius dpr...@gmail.com wrote: Not only do we feel entitled, we ARE entitled to an open and honest explanation when open and honest communication is offered and promised to us. There are two possible paths to follow: a) Give us spin, and don't promise open and honest communication. b) Promise us open and honest communication, and give us exactly that, not spin. Those are the two paths that do not undermine credibility, because then we know what to expect, and we get what we expect. On Apr 12, 10:34 am, notinfluential notinfluent...@gmail.com wrote: On Apr 12, 2:44 am, Jason Rundell jason.rund...@gmail.com wrote: When will Twitter answer: 1) Why did Twitter acquire Tweetie? 2) What is Twitter planning to do with Tweetie? Since when does Twitter owe you or any of us any sort of explanation for their business practices? Lemme get this straight. Twitter is FREE. The Twitter API is public, well documented, and FREE. Our privilege is to build tools and businesses on top of Twitter's FREE services. Twitter doesn't want a cut of your business. They don't require approval of your apps. But for some reason you (and others) feel entitled to an explanation, or details somehow outlining their strategy and practices? The tone of this group never ceases to amaze me. Get back to coding and building cool stuff. @notinfluential -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Some thoughts leading up to Chirp
also, I know no one wants to spill beans for the sake of spammers, but can team platform shed some light on app suspensions? obviously, there are the clear no no's but I have had an app suspended because the title was analytics, thus some reserved word for twitter inc. Also, do denial of oAuth requests come into play? On Tue, Apr 13, 2010 at 4:56 PM, Jason Rundell jason.rund...@gmail.comwrote: Well said Dewald! You've captured exactly how I feel about this. On Apr 13, 12:07 am, Dewald Pretorius dpr...@gmail.com wrote: Not only do we feel entitled, we ARE entitled to an open and honest explanation when open and honest communication is offered and promised to us. There are two possible paths to follow: a) Give us spin, and don't promise open and honest communication. b) Promise us open and honest communication, and give us exactly that, not spin. Those are the two paths that do not undermine credibility, because then we know what to expect, and we get what we expect. On Apr 12, 10:34 am, notinfluential notinfluent...@gmail.com wrote: On Apr 12, 2:44 am, Jason Rundell jason.rund...@gmail.com wrote: When will Twitter answer: 1) Why did Twitter acquire Tweetie? 2) What is Twitter planning to do with Tweetie? Since when does Twitter owe you or any of us any sort of explanation for their business practices? Lemme get this straight. Twitter is FREE. The Twitter API is public, well documented, and FREE. Our privilege is to build tools and businesses on top of Twitter's FREE services. Twitter doesn't want a cut of your business. They don't require approval of your apps. But for some reason you (and others) feel entitled to an explanation, or details somehow outlining their strategy and practices? The tone of this group never ceases to amaze me. Get back to coding and building cool stuff. @notinfluential -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: New methods for pending follow requests
Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 7:32 pm, Dana Contreras d...@twitter.com wrote: We've deployed two new methods for retrieving pending follow requests for protected users: * /friendships/incoming * /friendships/outgoing The incoming method returns a list of users who have pending requests to follow the authenticating user. The outgoing method returns a list of protected users for whom the authenticating user has pending follow requests. Both methods return 5000 user IDs per page. Cursors are provided in the unlikely event that you need to page through a list of more than 5000 pending follow requests. Full documentation is here:https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-in...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-ou... Enjoy! -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Some thoughts leading up to Chirp
Peter, It's probably better to ask those questions in a new thread. With all the media attention, these Tweetie-related threads are probably still a little too hot or toxic for Twitter employees to reply on them. On Apr 13, 9:28 pm, Peter Denton petermden...@gmail.com wrote: also, I know no one wants to spill beans for the sake of spammers, but can team platform shed some light on app suspensions? obviously, there are the clear no no's but I have had an app suspended because the title was analytics, thus some reserved word for twitter inc. Also, do denial of oAuth requests come into play? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] chirp questions for non-attendee's
Thanks to Dewald's advice, I started a new thread for questions those of us not attending chirp could throw out: *Mine are:* I know no one wants to spill beans for the sake of spammers, but can team platform shed some light on app suspensions? obviously, there are the clear no no's but I have had an app suspended because the title was analytics, thus some reserved word for twitter inc. Also, do denial of oAuth requests come into play? Cheers Peter -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: New methods for pending follow requests
Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? no - there is not. its following the theory that a malicious client could then accept friend requests to your protected account without your knowledge. I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? to display to the end user. for the end user to take action, a twitter client could redirect them to a twitter.com site. For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. users/lookup would help with that. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] Re: Basic Auth Deprecation
Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: New methods for pending follow requests
Allow/deny/cancel endpoints would certainly be the next logical step. As for user objects, you can pass the array of user IDs to users/lookup: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users-lookup On Tue, Apr 13, 2010 at 5:13 PM, Naveen Ayyagari nav...@getsocialscope.comwrote: Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 7:32 pm, Dana Contreras d...@twitter.com wrote: We've deployed two new methods for retrieving pending follow requests for protected users: * /friendships/incoming * /friendships/outgoing The incoming method returns a list of users who have pending requests to follow the authenticating user. The outgoing method returns a list of protected users for whom the authenticating user has pending follow requests. Both methods return 5000 user IDs per page. Cursors are provided in the unlikely event that you need to page through a list of more than 5000 pending follow requests. Full documentation is here: https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-in...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-ou. .. Enjoy! -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject. -- Dana Contreras Twitter Platform Team http://twitter.com/DanaDanger
[twitter-dev] Re: New methods for pending follow requests
I can understand the security issue with providing an endpoint. However, I am not sure there is a lot of value in displaying the information in a client, when the user would then be forced to leave the application, open a browser, possibly login, then click pending requests, then find the user they want to approve from the list they had already been reading, then finally be able to take action to approve or deny. Maybe twitter could consider some providing a url that a client can launch that would take them directly to the approval for a user. Ideally this would work for m.twitter.com and twitter.com Already there is: http://m.twitter.com/friend_requests which asks the user to login and then takes them directly to friend_requests page. However it does not seem to be optimized on m.twitter.com for mobile clients, and is acutally quite unsightly and difficult to navigate on my BlackBerry (The Curve 8310 which is one of the most common BlackBerry models in the wild right now) Maybe friend_requests could be extended to allow something like: http://m.twitter.com/friend_requests/UID or http://m.twitter.com/friend_requests?id=uid This would allow a client to launch a browser and twitter to display a simple accept/reject page directly without much additional user interaction. When browsing on a mobile client, the fewer clicks it takes a user to take a specific action, the more likely they are to engage. Actually, a slightly more complex implementation (maybe overkill), but may provide better user experience: http://m.twitter.com/friend_requests?src_id=uidtarget_id=uid Where src_id is the uid of the user making the request (i.e. if I was using this from my account src_id would be my uid and target_id would be the uid of the user I want to approve or reject). By including the src_id, twitter can determine if there is a current twitter session in the browser and if the src_id is equal to the uid of current session, then a login page may not be required and can skip the login step. Otherwise, just let the user login, then take them directly to the requested approval page. This version simply covers the case where the user is logged in as one user on the website, but as a different user in a client.. As I said, it may be overkill, and may be acceptable to just display an error message if the request is invalid. I think I was clear, but if not feel free to tear apart my assumptions or if there is some security risk I am not considering with this type of implementation? --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 9:06 pm, Raffi Krikorian ra...@twitter.com wrote: Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? no - there is not. its following the theory that a malicious client could then accept friend requests to your protected account without your knowledge. I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? to display to the end user. for the end user to take action, a twitter client could redirect them to a twitter.com site. For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. users/lookup would help with that. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com wrote: we'll make sure to message it long before hand! I'm still unclear what people who use 'curl' will do after basic auth is deprecated. Is there an OAuth for the commandline? If so: pointers, please. TjL
Re: [twitter-dev] chirp questions for non-attendee's
I had an app suspended because it was on the same domain as another app and it appeared to have the same functionality. I was setting up a test version. Guess that's a no-no. On Tue, Apr 13, 2010 at 5:58 PM, Peter Denton petermden...@gmail.comwrote: Thanks to Dewald's advice, I started a new thread for questions those of us not attending chirp could throw out: *Mine are:* I know no one wants to spill beans for the sake of spammers, but can team platform shed some light on app suspensions? obviously, there are the clear no no's but I have had an app suspended because the title was analytics, thus some reserved word for twitter inc. Also, do denial of oAuth requests come into play? Cheers Peter -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Basic Auth Deprecation
Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] chirp questions for non-attendee's
On Wed, Apr 14, 2010 at 02:58, Peter Denton petermden...@gmail.com wrote: Thanks to Dewald's advice, I started a new thread for questions those of us not attending chirp could throw out: Why not use Google Moderator for this? People could promote questions so those that interest non attendees the most could be thrown in. http://www.google.com/moderator/#0 Mathias. -- To unsubscribe, reply using remove me as the subject.
