Re: [twitter-dev] user stream best practices
I understand. There's lots of sausage making going on behind the scenes. You make it the best you can. Often for reasons that I cannot hope to understand. ;-) Let me stop being metaphysical and boil this down to a simple bug report: There is no documentation of how to get from the schema of the User Stream API to the schema of the REST API. Here's why this is a problem: The REST API divides and filters data, sometimes in some non-obvious ways. User streams divide the data less. It's the clients job to fetch backfill from one API, stream from the other, and display the result such that the display is consistent no matter which API the tweets came from. In practice when I compare the clients that use streams, they're all falling down in a few places. Here's an example 1: I retweet a tweet from my Home timeline. In Twitter.com it does NOT appear In Client A it DOES appear (but not if fetched from backfill) In Client B it does NOT appear. And example 2: I retweet a tweet from a list that is not in my Home timeline. In Twitter.com it DOES appear In Client A it DOES appear In Client B it does NOT appear. (but does if fetched from backfill) So, it looks to me like twitter.com seems to be de-duplicating the original tweets of retweets. Client A de-duplicates only regular tweets letting all retweets through. Client B remove all retweets that i create. Both clients have different behavior for streaming than they do for backfill. * Client A is my client (Kiwi), Client B is a very popular streaming client on the Mac. I have not been able to find any client that behaves consistently between backfill and streaming. All fail on at least one corner case that I'm aware of. There are subtle behaviors, some undocumented, that each developer must find, analyze and implement. It's difficult. We're not doing so well. In order to make bug-free clients we need Twitter to make the schema the same, or (if that sausage is too expensive) document how they differ. isaiah http://twitter.com/isaiah On Dec 18, 2010, at 7:48 AM, John Kalucki wrote: Yes, our model does externalize some development and hosting costs onto clients. But, we tend to only externalize cost when issues would be far cheaper, in aggregate, to solve on the client, or would be intractable to solve on our end and might otherwise prevent the launch of the feature. We try to balance this cost externalization very carefully and with all due concern for everyone's time. Our resources are limited, and our reasoning may not always be immediately obvious, but we're trying to get you as much data as possible, as efficiently as possible for everyone. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Tue, Dec 14, 2010 at 2:07 PM, Isaiah Carew isa...@me.com wrote: In other words, if I want to disambiguate the stream, I have to filter it myself. Well, humph… Not impossible, just a pain in the butt. From an information organization standpoint, it seems odd: The REST API is broken out into separate calls. The stream has everything glommed together. It would be no big deal if you only needed one or the other, but you have to do backfill with the REST API, so you always need both. The REST API has hierarchy in the endpoints. The Stream API has hierarchy in the schema. Why not make the hierarchies (at least roughly) the same? You don't have to answer, I'm just mouthing off. I'll get back to work writing a track-term to nspredicate converter. ;-) isaiah http://twitter.com/isaiah On Dec 13, 2010, at 9:30 AM, John Kalucki wrote: Roughly: If the tweet is from a following, place it in the home timeline. If the tweet refers to the user (to or from), or contains the @screenname place it in mentions If it's a message - messages. What remains is probably a track term. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Fri, Dec 10, 2010 at 5:58 PM, isaiah isa...@mac.com wrote: Hi, I'm implementing user streams in my client and looking for some advice on best practices. My client supports viewing multiple timelines at the same time, so it's quite possible to, for example: view a saved search, the user's own home timeline, and another user's recent tweets. Of course, I'd love to implement these in user streams. My concern is that if each of these timelines were to open a separate stream simultaneously, then the user could easily cross over their limit of active streams. Another potential solution seems to be adding the search and the second user as tracking parameters to a single user stream. That works fine and the track parameter limitations seem to be similar to the limitations of the UI/UX of my app, so it seemed like a good fit. The challenge is that once track parameters are added to the stream I get a whole bunch of new statuses returned but i can't tell which are associated with each parameter
Re: [twitter-dev] user stream best practices
In other words, if I want to disambiguate the stream, I have to filter it myself. Well, humph… Not impossible, just a pain in the butt. From an information organization standpoint, it seems odd: The REST API is broken out into separate calls. The stream has everything glommed together. It would be no big deal if you only needed one or the other, but you have to do backfill with the REST API, so you always need both. The REST API has hierarchy in the endpoints. The Stream API has hierarchy in the schema. Why not make the hierarchies (at least roughly) the same? You don't have to answer, I'm just mouthing off. I'll get back to work writing a track-term to nspredicate converter. ;-) isaiah http://twitter.com/isaiah On Dec 13, 2010, at 9:30 AM, John Kalucki wrote: Roughly: If the tweet is from a following, place it in the home timeline. If the tweet refers to the user (to or from), or contains the @screenname place it in mentions If it's a message - messages. What remains is probably a track term. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Fri, Dec 10, 2010 at 5:58 PM, isaiah isa...@mac.com wrote: Hi, I'm implementing user streams in my client and looking for some advice on best practices. My client supports viewing multiple timelines at the same time, so it's quite possible to, for example: view a saved search, the user's own home timeline, and another user's recent tweets. Of course, I'd love to implement these in user streams. My concern is that if each of these timelines were to open a separate stream simultaneously, then the user could easily cross over their limit of active streams. Another potential solution seems to be adding the search and the second user as tracking parameters to a single user stream. That works fine and the track parameter limitations seem to be similar to the limitations of the UI/UX of my app, so it seemed like a good fit. The challenge is that once track parameters are added to the stream I get a whole bunch of new statuses returned but i can't tell which are associated with each parameter. Or, well, I couldn't figure out how to tell short of building a regex for each of my track parameters and trying to sort the items by hand (yuck!). So my question: 1. Is there some way to disambiguate statuses returned as a specific track parameter from those returned for other reasons? 2. Is there some other way to skin this cat that I'm missing? Thanks, Isaiah -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] user stream best practices
Hi, I'm implementing user streams in my client and looking for some advice on best practices. My client supports viewing multiple timelines at the same time, so it's quite possible to, for example: view a saved search, the user's own home timeline, and another user's recent tweets. Of course, I'd love to implement these in user streams. My concern is that if each of these timelines were to open a separate stream simultaneously, then the user could easily cross over their limit of active streams. Another potential solution seems to be adding the search and the second user as tracking parameters to a single user stream. That works fine and the track parameter limitations seem to be similar to the limitations of the UI/UX of my app, so it seemed like a good fit. The challenge is that once track parameters are added to the stream I get a whole bunch of new statuses returned but i can't tell which are associated with each parameter. Or, well, I couldn't figure out how to tell short of building a regex for each of my track parameters and trying to sort the items by hand (yuck!). So my question: 1. Is there some way to disambiguate statuses returned as a specific track parameter from those returned for other reasons? 2. Is there some other way to skin this cat that I'm missing? Thanks, Isaiah -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Why is Basic Auth still enabled on some sources?
The bonus is that it's a way to still use plain old curl for testing. Awesome! On Sep 13, 9:21 am, Dewald Pretorius dpr...@gmail.com wrote: They must have known that this was going to be discovered. We're developers. We like building, testing, and breaking stuff. Unequal applications of the rules. Happens all the time. Months after you've disabled something at the request of Twitter, you find well- known services that do exactly the same thing with apparent impunity in a much worse form than you did. On Sep 13, 10:40 am, funkatron funkat...@gmail.com wrote: Read on this post:http://blog.nelhage.com/2010/09/dear-twitter/ Tested just now:http://gist.github.com/577273 If I pass source=twitterandroid, it appears to work on all API methods. In light of basic auth being disabled, why does this work? -- Ed Finklerhttp://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com -- 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] YFrog/ImageShack and invalid username or verification url error
Did you ever get to the bottom of this? I've been getting this same response from yFrog -- but all of the other oAuth Echo supporting services seem to be working just fine. isaiah http://twitter.com/isaiah On Jul 20, 2010, at 4:21 PM, DWF wrote: Anyone else seeing this? We're implementing OAuth Echo for uploading photos. We've knocked down Posterous TwitPic with few issues. So we know our signing is working. We now have an ImageShack API key and when we attempt to upload we get this response: ?xml version=1.0 encoding=UTF-8? rsp stat=fail err code=1001 msg= Invalid username or verification URL specified/ /rsp There's one comment on their Google Group with someone else getting this suddenly after having successful code for a while. Thoughts? --dwf
Re: [twitter-dev] YFrog/ImageShack and invalid username or verification url error
Oh, never mind. I've answered my own question. It looks like yFrog only supports XML for the https://api.twitter.com/1/account/verify_credentials.xml In other words, they don't accept https://api.twitter.com/1/account/verify_credentials.json At least that's my understanding from their docs. Someone correct me if I'm wrong here. So, I've dropped 'em for now from Kiwi. Just too much pain all around. For those interested I've had really good luck with TwitPic, TwitrPix, and TwitGoo -- all seem to support echo well. I've implemented support using both my own OBJ-C and on the iPhone using Aral's X-Auth libs on GitHub. isaiah http://twitter.com/isaiah On Jul 26, 2010, at 4:49 PM, Isaiah Carew wrote: Did you ever get to the bottom of this? I've been getting this same response from yFrog -- but all of the other oAuth Echo supporting services seem to be working just fine. isaiah http://twitter.com/isaiah On Jul 20, 2010, at 4:21 PM, DWF wrote: Anyone else seeing this? We're implementing OAuth Echo for uploading photos. We've knocked down Posterous TwitPic with few issues. So we know our signing is working. We now have an ImageShack API key and when we attempt to upload we get this response: ?xml version=1.0 encoding=UTF-8? rsp stat=fail err code=1001 msg= Invalid username or verification URL specified/ /rsp There's one comment on their Google Group with someone else getting this suddenly after having successful code for a while. Thoughts? --dwf
[twitter-dev] xauth token exchange failing
Hi, I'm seeing across the board failure of xAuth token exchange for my app, Kiwi. The app has not changed for months and is in use by thousands of users. So I don't think it's something I've done recently. Is it related to what I'm seeing on status.twitter.com? Is there a way to tell whether the problem is: twitter, my IP, my app, or my accounts? Is there something in the HTTP response tea leaves that can tell me more info? Currently I'm getting: Status = 500 Internal Server Error; isaiah http://twitter.com/isaiah
Re: [twitter-dev] xauth token exchange failing
The status page at: dev.twitter.com/status says things are all go -- but I'm still getting 500s during token exchange. Any updates? isaiah http://twitter.com/isaiah On Jul 19, 2010, at 12:55 PM, Taylor Singletary wrote: Hi Isaiah, This is related to the same issue you see on status.twitter.com -- it's effecting many user-related write operations (including, for instance, instantiating an access token on behalf of a user). We are working to resolve the issue. Taylor On Mon, Jul 19, 2010 at 12:10 PM, Isaiah Carew isa...@me.com wrote: Hi, I'm seeing across the board failure of xAuth token exchange for my app, Kiwi. The app has not changed for months and is in use by thousands of users. So I don't think it's something I've done recently. Is it related to what I'm seeing on status.twitter.com? Is there a way to tell whether the problem is: twitter, my IP, my app, or my accounts? Is there something in the HTTP response tea leaves that can tell me more info? Currently I'm getting: Status = 500 Internal Server Error; isaiah http://twitter.com/isaiah
Re: [twitter-dev] Re: xauth token exchange failing
OK, good to know. Just want to make sure it's not just me. Misery loves company, I guess. :-P isaiah http://twitter.com/isaiah On Jul 19, 2010, at 2:54 PM, Tim Davies wrote: Im getting the same isalah. Twitter are aware of the issue. its during handshake for creating new tokens and maybe linked to several other OAuth issues that came to attention this morning. Im hoping it will be fixed shortly!
Re: [twitter-dev] Re: Rate limits should be resetting now
Great news. I'm crossing my fingers too. isaiah http://twitter.com/isaiah On Jul 7, 2010, at 8:32 PM, Raffi Krikorian wrote: 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
[twitter-dev] Re: Rate limits should be resetting now
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
[twitter-dev] lockouts are the new black
Lockouts are now common and frequent for everyday users doing normal things. I have dozens of reports from my users being locked out. And I've noticed that nearly every Twitter client developer has posted about this in a blog or Tweet. Several in just the last 24 hours. I know that the goal is to improve the latency and failures (i.e. whales) that you guys were seeing during the world cup. But creating lockouts to reduce failures is cutting off your nose to spite your face. Failures, lagging, and latency are frustrating but at least *feel* egalitarian. Service disruption is nothing new -- we understand it whether it's ATT, temporary power failures, or whatever. Lockouts feel punitive and targeted. Users really really don't like it. I think it's safe to say that this is now *the* critical issue. All other twitter concerns seem dwarfed by this massive problem. isaiah http://twitter.com/isaiah
Re: [twitter-dev] lockouts are the new black
John, Do you measure the number of lockouts? Or maybe a better question is: do you have metrics on how reducing rate limits is impacting users? isaiah http://twitter.com/isaiah On Jul 6, 2010, at 9:10 AM, John Kalucki wrote: These lockouts are almost certainly due to a performance optimization intended to reduce network utilization by increasing physical reference locality in a multi-level loosely-coordinated best-effort distributed cache. Not easy to get right, and the engineers involved are working to resolve the issue. There's absolutely no intention to lock people out. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Tue, Jul 6, 2010 at 9:00 AM, Isaiah Carew isa...@me.com wrote: Lockouts are now common and frequent for everyday users doing normal things. I have dozens of reports from my users being locked out. And I've noticed that nearly every Twitter client developer has posted about this in a blog or Tweet. Several in just the last 24 hours. I know that the goal is to improve the latency and failures (i.e. whales) that you guys were seeing during the world cup. But creating lockouts to reduce failures is cutting off your nose to spite your face. Failures, lagging, and latency are frustrating but at least *feel* egalitarian. Service disruption is nothing new -- we understand it whether it's ATT, temporary power failures, or whatever. Lockouts feel punitive and targeted. Users really really don't like it. I think it's safe to say that this is now *the* critical issue. All other twitter concerns seem dwarfed by this massive problem. isaiah http://twitter.com/isaiah
[twitter-dev] Re: Rate limit reduction to 75?
Given that Raffi told us that that Rate Limits would be going to 10X by chirp -- it almost sounds like a joke now, but he definitely seemed serious -- we designed features that were already constrained at 350 calls/hr. Now at these dramatically lower limits, even with dynamic adjustments, many features are failing regularly and our customers are screaming. Clearly cutting features from our app is pretty much the only way forward. However we were already having trouble trying to maintain some semblance of feature parity with Twitter.com -- which is what our users are demanding. With the failures and changes combined our users are going to be marching with pitchforks very and torches looking for heads to chop very soon. I'm not asking for any specific action here. Merely passing along the anger that we see just in case you weren't aware of it. Isaiah
Re: [twitter-dev] xAuth Approval?
On Apr 26, 2010, at 8:54 PM, Raffi Krikorian wrote: 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 ! It's so tempting to respond in kind to that sort of professionalism. Isaiah -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] User Stream's API usage
Any chance on getting access to a beta of these from outside chirp? I had to
come home this afternoon and didn't get to play too much while i was there, but
would be really interested in playing more. I understand it's not ready for
roll out. Just looking to start the development process.
isaiah
http://twitter.com/isaiah
On Apr 14, 2010, at 9:26 PM, John Kalucki wrote:
I should have encouraged folks to understand the Streaming API first. You can
read up on all the details here:
http://apiwiki.twitter.com/Streaming-API-Documentation
But, for a prototype, just dive right in.
-John
On Wed, Apr 14, 2010 at 9:15 PM, Mark McBride mmcbr...@twitter.com wrote:
Some sample APIs...
curl -uyouruser:yourpass http://chirpstream.twitter.com/2b/user.json
Will give you a stream of your home timeline, social activity from your
friends, and direct messages.
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.json?track=#chirp;
Will give you all of the above, plus any tweets matching #chirp
Does that clear it up? If not, I'm currently near The Coop.
---Mark
http://twitter.com/mccv
On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts kovas.bog...@gmail.com wrote:
Hi,
Is there any description of how to use this? I don't understand how to use
track with this or what is generally available for hack day. Thanks!
On Apr 14, 2010, at 4:17 PM, John Kalucki j...@twitter.com wrote:
Email me your account name. You are in, but not getting data. Also, is this
account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
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 -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
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 -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
hey look, i'm not looking for a flame war here. what twitter did just seemed a bit less than nice to me, that's all. this is the forum for developer feedback, if i'm not mistaken. i was feeding back. you've got a lot of valid points, and maybe a few stretched analogies, too. if you'd like my thoughts on this i posted a nicer, more thought out article: http://yourhead.tumblr.com/post/516626319/le-roi-est-mort-vive-le-roi i'd be happy to continue to debate via email or at chirp (yes, i'm going, i'm a glutton for punishment, shoot me). see you guys tomorrow, isaiah http://twitter.com/isaiah On Apr 12, 2010, at 6:08 PM, TjL wrote: On Mon, Apr 12, 2010 at 11:54 AM, Isaiah Carew isa...@me.com wrote: 1. You're decimating the client market on every platform but Windows. The iPhone and Mac versions of Tweetie have been a) dominant and b) free (ad-supported). If your app was set to compete with Tweetie 2 on the Mac and iPhone before this, it still is. If it wasn't, it still isn't. Also, you've had a LOT of time to compete against Tweetie on the Mac. If you missed the window, well, sorry. 2. You're killing any potential for innovation or investment. Oh, baloney. Ask BareBones how BBEdit has done competing against the free version of TextEdit. In 2010, you are going to compete with free. That sucks, but it's the reality of the situation. You'd better have a plan in place for it. I'm still giving EchoFon for Mac and iPhone a serious look. Why? Because it has features Tweetie doesn't. I'd start with looking at what Tweetie doesn't offer. What does it make too difficult? really wish i knew why so many twitter clients are against keyboard navigation and proper highlighting http://twitter.com/bynkii/status/12026843737 (21 hours ago… Via Tweetie) Tweetie breaks several Mac UI principles (click to select a word comes to mind). A good UI for filtering tweets based on strings (SXSW comes to mind). Sync between Mac and iPhone. Push notifications for mentions. Push notifications for mentions only for people who follow you. Push notifications for mentions only for people you follow. Push notifications of new posts by only a select group of people (like SMS notifications, but without SMS). I'm still waiting for someone to build a big enough database to get relationship data in-app (x person is also followed by these people you follow, as one example). There are a half-dozen ideas off the top of my head. 3. You have no clear (public) plan for any innovation yourself. Have you published your plan for innovation somewhere? I'm under the impression that *most* companies keep their future plans a fairly well guarded secret. (Well, except for Microsoft, who tell you what they are going to do and then do 1/100th of it 4 years later.) TjL -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Twitter buying Tweetie
Loren, congrats man. I think the best man won. Hard work and dedication to perfection paid off in spades. You deserve the accolades (and the $$$). Oh and everyone else? Thanks for playing. I'll catch you all next week on the Facebook forums. Anyone have the odds on who Twitter will pick as the winners on the other platforms? Isaiah On Apr 9, 2010, at 7:25 PM, Tim Haines tmhai...@gmail.com wrote: Dewald, I'm surprised that you failed to mention that Twitter can also advertise the heck out of it on Twitter.com and via tweets etc - millions for further development - and very significant marketing resources available too. I disagree with your sentiment though. Twitter's free to build or buy whatever they want to. As a third party developer it's one of the risks you take on when you start building on someone else's platform. If you don't acknowledge that, you're being naive. Sure it's going to suck if they do something to harm Favstar, but I'm aware it's a risk - and I'm going to try and keep innovating to keep Favstar useful for users regardless. Tim. On Sat, Apr 10, 2010 at 2:18 PM, Dewald Pretorius dpr...@gmail.com wrote: It's great for Loren. But, there's a problem, and I hope I'm not the only seeing it. Twitter has just kicked all the other developers of Twitter iPhone (and iPad) clients in the teeth. Big time. Now suddenly their products compete with a free product that carries the Twitter brand name, and that has potentially millions of dollars at its disposal for further development. It's really like they're saying, We picked the winner. Thanks for everything you've done in the past, but now, screw you. This would not have been such a huge deal if the developer ecosystem did not play such a huge role in propelling Twitter to where it is today. Please correct me if I'm wrong. On Apr 9, 10:41 pm, Tim Haines tmhai...@gmail.com wrote: Before anyone rants, let me say congratulations Loren, and congratulations Twitter. Awesome! Totally awesome! :-) Tim. -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What happened, happened.
It would be great if Twitter would clarify things online. I'm sure I'm not the only one who thinks that it's time to cut losses and move on - starting with Chirp. Frankly I'm not sure I see much point in attending Chirp any more. Isaiah On Apr 9, 2010, at 8:26 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Let there be no doubt that not only will Chirp be an opportunity for developers to learn and talk to platform developers Twitter employees directly about what will obviously be a hot topic on everyone's mind, but Chirp will also in itself be a platform for Twitter to clarify existing capabilities and introduce new platform opportunities available to our obviously instrumental developer community. No one Twitter experience will ever define Twitter. No one app will ever define a platform. Not all use cases, analytical opportunities, clients, redefinitions, evolutions of, extrapolations on, libraries for the API of, insights for, integrations of, thoughts on, run-on-sentences-written-about, financial opportunities, or choices offered to consumers in the Twitter universe have been explored. @episod
Re: [twitter-dev] api stability vs. risk
we strive to do everything we possibly can to keep everything as backwards compatible as possible -- in fact, we jump through many hoops to do it. maybe it's just me, but backwards compatible seems like a liability rather than a benefit. attempting backwards compatibility constrains your innovation without providing any real insulation from changes to customers. however: we will change things. backwards compatibility requires that you all have -good- XML and JSON parsers that can accept the addition of new parameters without breaking. agreed. and my anecdotal situation could have been resolved if my library didn't have that bug. yep. you're right. ... but you've also missed the point. the point is that as the number of users of your API grows, EVERY change you make WILL stimulate SOME bug. it just doesn't matter how careful you are, i am, or how great my libraries are. the only hope that we have of keeping those bugs from reaching real customers is to test the changes before deploying. step back for a moment. think of the user. they don't experience the API and the client and the backend as separate entities. they just see Twitter as a single whole. changes to the API are making revisions to that whole. it seems wise that we have some way to do integration testing with the other parts before letting the customer see the changes. right now, you're introducing changes to a complex system without testing their real world results on your customers. it pains me to hear that you all think that talking to us is like talking to a brick wall each time i post to this list you respond in this way. i'm not sure what i'm doing to provoke this feeling, but i assure you it's not what I think at all. you guys are whatever the opposite of a brick wall is. i apologize, i must have a gruff tone. i'm not angry. in fact i enjoy the back and forth that we have with the API team. but i'll see if i can't just tone it down a notch. :-P Isaiah -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
So will they be monotonically increasing? That seems to be the key question. If they're not necessarily monotonic with respect to their date, then it seems like it would be a pretty painful change. Isaiah To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Obj-C xAuth Demo
Hi guys, For those looking to implement xAuth for Mac OS X, I've set up a complete working demo app. It uses MGTwitterEngine and the OAConsumer libs to do the dirty work and just adds enough to implement the new xAuth flow. I've tried to keep the code as simple to understand as possible, but it does the basics: - Adds the required parameters to the access token request - Overloads the request method in MGTwitterEngine with a signed request. - Shows how to store the access key in the Mac OS X Keychain. - Performs a basic tweet post and fetches the home timeline. It's just meant to help people get going and see a complete solution in action or a as a resource to compare their own solution. I did one of these for OAuth last summer and it was pretty popular, so I figured I'd just keep the ball rolling. You can see the github repo here: http://github.com/yourhead/xAuth_ObjC_Test_App And if you're not approved for xAuth you can download a complete Mac OS X binary that was compiled with working keys -- in case you just need something simple to TCP dump. You can download the binary here: http://github.com/yourhead/xAuth_ObjC_Test_App/downloads I'd be pleased with any sort of feedback, about the code, about the app, or just ways that it could be made more approachable for people new to the topic. isaiah http://twitter.com/isaiah/ http://twitter.com/kiwi-app/
Re: [twitter-dev] Re: xAuth
Try passing in nil as the token. The access token request should be similar to how you used to perform the request token request. The best explanation (and they one that helped me) is from Steve Reynolds: http://ke-we.net/7u isaiah http://twitter.com/isaiah On Mar 1, 2010, at 1:26 PM, Berto wrote: Hey Isaiah, What do you mean by default token? I'm working on getting xAuth implemented, but I seem to get a 401 even though I received an email I was approved. I've tried using a token I get from request_token (which from your reply, doesn't seem like I need to be doing) and not passing a token at all. On Feb 27, 1:45 pm, Isaiah Carew isa...@me.com wrote: i did manage to get xauth working this morning thanks to @SteveReynolds. the big epiphany (Steve's, not mine) was that there is no token exchange at all. in fact you don't even seem to need to acquire a request token ever. you simply jump directly to the auth token request and pass in your default token. it seems to make sense to me now, it was just a leap that i didn't make on my own. i just thought i'd post this in case anyone else out there is stuck too. when it's a bit more cleaned up, i'll post my results to github. isaiahhttp://twitter.com/isaiah On Feb 27, 2010, at 9:37 AM, Aral Balkan wrote: Like a n00b, I didn't include the id of my app in my original support request (I hadn't registered it since I wasn't using oAuth previously) and so it looks like I've missed the initial boat :( Got a message back asking for my app id so I registered Feathers and got back to the ticket but apparently the Twitter helpdesk/zendesk is down (http://help.twitter.com) so not sure if my ticket was updated. Would really appreciate it if anyone can look into the ticket (Ticket #863920) Thanks :) Aral On Sat, Feb 27, 2010 at 6:47 AM, Isaiah Carew isa...@me.com wrote: So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). snip
[twitter-dev] missing tweets
Several users are reporting missing tweets over the past 8 hours. The problem exists even on twitter.com. One of my accounts is also affected. Even though @kiwi_app and @isaiah follow many of the same people, the @isaiah account is empty for the past 8 hours except for it's own tweets. I haven't seen anything new on http://status.twitter.com about this, so I thought I'd post it. isaiah http://twitter.com/isaiah
[twitter-dev] xAuth
So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). So I gave it a shot. No dice. Seems to behave the same way as yesterday. So, now I've tried all three of my registered app credentials, just in case. Same 401 result. I've tried changing all the switches on the Twitter App configuration page. Then on all thee apps. Nope. Nope. Nope. Should the xauth parms be included in the base string for generating the signature? My guess is yes, but I couldn't find anything very conclusive after scouring the oauth spec and the xauth paper. I've tried both -- with all my apps -- with all the switches. Nope ^ 4. The number of ambiguous variables is pretty large here. Would anyone on the api team like to throw me a bone and tell me: - which app they enabled? - if there are specific settings on the App page that should be set or not set? (Client or Web? Login with Twitter?) - i'd really love to know the specifics about the xauth params and the signature. i'm sure it's in some doc somewhere -- a link to a page in a doc would be super. Just nailing down a few of those combinations will make the debug process a lot smoother. Currently I'm using an implementation that works very well pre-xauxth and is successfully getting request tokens without any problems. If I switch it over to PIN mode things seem to work well for all three apps of my Twitter apps. It generates the required headers, and exchanges request tokens for oauth tokens reliably. Unfortunately the error messages aren't very interesting: 401: Unauthorized. feel free to email for more techy details. i've got loads. ;-) isaiah http://twitter.com/isaiah
Re: [twitter-dev] xAuth
i did manage to get xauth working this morning thanks to @SteveReynolds. the big epiphany (Steve's, not mine) was that there is no token exchange at all. in fact you don't even seem to need to acquire a request token ever. you simply jump directly to the auth token request and pass in your default token. it seems to make sense to me now, it was just a leap that i didn't make on my own. i just thought i'd post this in case anyone else out there is stuck too. when it's a bit more cleaned up, i'll post my results to github. isaiah http://twitter.com/isaiah On Feb 27, 2010, at 9:37 AM, Aral Balkan wrote: Like a n00b, I didn't include the id of my app in my original support request (I hadn't registered it since I wasn't using oAuth previously) and so it looks like I've missed the initial boat :( Got a message back asking for my app id so I registered Feathers and got back to the ticket but apparently the Twitter helpdesk/zendesk is down (http://help.twitter.com) so not sure if my ticket was updated. Would really appreciate it if anyone can look into the ticket (Ticket #863920) Thanks :) Aral On Sat, Feb 27, 2010 at 6:47 AM, Isaiah Carew isa...@me.com wrote: So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). snip
Re: [twitter-dev] Which api url to use?
i'm bound to forget this in about an hour. is this old/new versioned/not listed somewhere in the API docs? On Feb 22, 2010, at 9:42 AM, Ryan Alford wrote: Yes, those are the ones I am talking about. Ryan On Mon, Feb 22, 2010 at 12:41 PM, Raffi Krikorian ra...@twitter.com wrote: hi ryan. yup - those are the original update methods, right? like http://twitter.com/statuses/update.xml http://twitter.com/statuses/update.json we haven't set a deprecation date for those yet - but developers should plan on it. please start to migrate to the api.twitter.com/1/ URLs. On Mon, Feb 22, 2010 at 9:26 AM, Ryan Alford ryanalford...@gmail.com wrote: Raffi, Just so you know, http://twitter.com/statuses/update.format; also works. That's what I have been using in my app until today(moved to the versioning). Ryan On Mon, Feb 22, 2010 at 12:23 PM, Raffi Krikorian ra...@twitter.com wrote: yeah - please use the /1 URLs. if api.twitter.com works without /1, then that's inadvertent, and we'll probably fix that. On Mon, Feb 22, 2010 at 9:18 AM, Ryan Alford ryanalford...@gmail.com wrote: I *believe* Twitter is moving to versioning the API(which is what the /1/ means..it's version 1). So I would use the URL with the /1/, since the other way be deprecated in the future. Ryan On Mon, Feb 22, 2010 at 11:19 AM, Dmitri Snytkine d.snytk...@gmail.com wrote: Is there a difference between using http://api.twitter.com/1/statuses/update.format and http://api.twitter.com/statuses/update.format (without the /1/)? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Which api url to use?
the docs wiki pages list the end-point URLs such as: http://search.twitter.com/search.format and http://api.twitter.com/1/statuses/home_timeline.format but it doesn't say much about the 1 being a version number, or about why some endpoints (e.g. search) have a different base URL than others, or why they were recently changed, or if/when we should change our apps, or if the old endpoints are depreciated. or more than likely, it probably does say all those things, i just missed it and was hoping the list could help me locate the docs. thanks, isaiah On Feb 22, 2010, at 11:02 AM, Ryan Alford wrote: Its actually listed on all of the twitter api method pages, except for the OAuth methods. Ryan Sent from my DROID On Feb 22, 2010 1:58 PM, Isaiah Carew isa...@mac.com wrote: i'm bound to forget this in about an hour. is this old/new versioned/not listed somewhere in the API docs? On Feb 22, 2010, at 9:42 AM, Ryan Alford wrote: Yes, those are the ones I am talking about. ...
Re: [twitter-dev] Introduce yourself!
hi, my name is isaiah ( @isaiah ). i'm a indie Mac/iPhone developer. my latest creation is Kiwi, a Mac Twitter client: http://kiwi-app.net/ i do lots of other fun stuff too: open source OAuth stuff: http://github.com/yourhead website layout tools: http://yourhead.com/ i tried to figure out when i started using twitter and the twitter api, but i'm not certain. more than a couple years, i'd guess. i joined this list to post about the challenges of the OAuth user experience on the desktop. and that's what the vast majority of my posts have been about. i'm very excited about xauth, i think it's going to be huge. i just wish that @twitterapi would switch it on, already. ;-) if Twitter would grant me one API wish it would be: a switch that worked on every API command that would enable extremely verbose output, error messages with detailed reasons for the error, and rate-limit details. i'd love to see which rate limit i was bumping into, what OAuth parameter i've screwed up, and exactly which parts of my request were not URL encoded correctly. i'll definitely be at chirp. you'll be able to find me at the after-party, i'll be the guy in the corner wearing a black t-shirt who's had one too many beers. you can count on it. isaiah http://twitter.com/isaiah
Re: [twitter-dev] Re: What's up with OAuth?
so excited about xAuth. i think this is really going to change the landscape in a big way. can't wait to get going. sent a message to a...@twitter.com -- that's all that's necessary to get going right? thanks again, isaiah On Feb 12, 2010, at 9:04 AM, tsmango wrote: Yep, I meant mobile native applications. This is really a wonderful idea! Very, very happy about this! On Feb 12, 11:15 am, Raffi Krikorian ra...@twitter.com wrote: if, of course, you mean a mobile native application, and not a mobile web application. mobile web applications still need to send their users through the regular oauth workflow. On Fri, Feb 12, 2010 at 8:15 AM, Raffi Krikorian ra...@twitter.com wrote: yup! that's the plan. sorry if it wasn't clear in the e-mail blast. On Fri, Feb 12, 2010 at 6:14 AM, tsmango tsma...@gmail.com wrote: Just to clarify, xauth will be available to mobile applications (who apply) going forward to authenticate users, not just a one time way to exchange stored usernames and passwords? On Feb 11, 10:18 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. this is a long overdue e-mail, but i wanted to tease out some of the directions that Twitter is going with OAuth. i want to touch upon four topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange, and basic authentication deprecation. *DELEGATION - OAuth Echo* twitter users love posting media on third-party sites, and delegation in identity verification is one of the major hurdles for an OAuth-enabled twitter client to succeed. i started a series of blog posts around the following problem: You're an OAuth enabled Twitter client, and you've already authorized your user. Your user wants to use a media providing service like TwitPic. TwitPic, currently, asks for the username and password of your user so it can store the photo on behalf of the Twitter user. You don't have that username and password, so how do you give the ability to TwitPic to verify the identity of your user? check out the proposal for what we're calling OAuth Echo athttp:// mehack.com/OAuth-echo-delegation-in-identity-verificatio. please feel free to comment there, or on the twitter development talk mailing listhttp://groups.google.com/group/twitter-development-talk(or, even just reach out to me directly). i think this experiment in engaging the community around designing this security/identity workflow has been definitely a success, and i feel we're rapidly converging on a solution for identity verification delegation. in parallel, we're going to start the process to engage our media providers in the conversation as well, and we're hopeful we can move this forward quickly. *OAUTH WRAP/2.0* OAuth is evolving, and we at Twitter are keeping up with it. that being said, we're keeping our eyes on OAuth WRAP and OAuth 2.0http://wiki.oauth.net/OAuth-WRAP. we like a lot about it: - it requires the use of SSL; - there is no custom signing mechanism -- you simply pass us a token, and that token is secured by SSL; and - it formalizes a bunch of profiles that we've been actively thinking about (e.g. a username/password exchange) in general, we really like WRAP/2.0 because it's just *so* easy to implement from the client side. there are no longer questions around creating the proper signature base string, etc. we're sure that developers will like it as well. we've started work on an internal implementation of OAuth WRAP and we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0 for a while. our hope is to get WRAP out the door soon (and before we finally deprecate basic authentication). *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth* @rsarver and @noradio announced that we are going to support a mechanism where a username and a password can be directly exchanged for an OAuth token and secret -- we're calling this xAuth. if you've been watching the mailing list, Seesmic Look http://seesmic.com/look has been a beta partner in testing xAuth exchange (and @abraham has already detailed how it works http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser.. .). because we're 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. that's still one of our use cases. another use case is around environments where software can't bring up a web browser (e.g. set top boxes, game consoles, embedded devices). we want to support those as well. you're going to have to apply to get access to this exchange mechanism (by sending e-mail to a...@twitter.com), but, in general, all applications except web applications will get access. we feel that the xAuth exchange allows for the best mix of security and user experience for desktop and possibly
Re: [twitter-dev] Re: Seesmic Look and the Source parameter
I check this topic about 10 times a day hoping for an update. To say I'm excited about this, doesn't really come close. I have my code prepped and ready for whenever this lands. But I think we can all wait Raffi to get better. Health trumps all things. And rightly so. @raffi Take it easy. Get better man. We can wait. isaiah http://twitter.com/isaiah On Feb 9, 2010, at 9:42 AM, Ryan Sarver wrote: Raffi, has walking pneumonia so we're giving him a few days slack time and we're afraid of what he would write while on meds :) On Tue, Feb 9, 2010 at 8:48 AM, Raffi Krikorian ra...@twitter.com wrote: in progress :P On Tue, Feb 9, 2010 at 12:18 AM, mynetx myne...@googlemail.com wrote: And where’s the announced post by Raffi? http://groups.google.com/group/twitter-development-talk/msg/56cd59f6d5a57db9 On Feb 8, 6:39 pm, Dewald Pretorius dpr...@gmail.com wrote: The info you're looking for is in this thread: http://groups.google.com/group/twitter-development-talk/browse_thread... On Feb 8, 2:45 am, mynetx myne...@googlemail.com wrote: How can Seesmic Look display its Source in the tweet metadata, when it asks for my user name and password? It would be interesting to know how Seesmic Look gets the Twitter API to return an OAuth Access Token and its secret from a user name / password API request input. Look is connecting to Twitter via the Dimebrain TweetSharp Library for C#, but as Seesmic's class is using obfuscated .NET IL code, I have not yet found out. Any insight appreciated. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: How Does TwittPic Works ?
Oh wow, oh wow, oh wow! On Feb 3, 11:49 am, Raffi Krikorian ra...@twitter.com wrote: it will be available publicly soon! On Wed, Feb 3, 2010 at 11:43 AM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, Have you tried it? There is no OAuth flow. I.e., the user types in his Twitter username and password. That's it. If it is indeed using OAuth, does that mean that the background requesting of tokens when you have the Twitter credentials is now available? Meaning, I can also now use it to convert all existing Twitter accounts to OAuth in one fell swoop? On Feb 3, 3:02 pm, Raffi Krikorian ra...@twitter.com wrote: seesmic look, i believe, is using oauth talking to api.twitter.com. On Tue, Feb 2, 2010 at 8:09 PM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, What's going on here? Your credibility is at stake here. You've been telling us in many posts that new apps must use OAuth to get a source attribution, and only old grandfathered apps have source attribution with Basic Auth. On Feb 2, 11:18 pm, Dewald Pretorius dpr...@gmail.com wrote: At first I thought they must have changed the old Seesmic source to Seesmic Look. But no. Here's a recent tweet from Seesmic: http://twitter.com/CathyBrooks/status/8570217879 And here's a recent one from Seesmic Look: http://twitter.com/adamse/status/8565271563 Seesmic Look uses Basic Auth. Does anyone else spot Mt Everest on this level playing field of ours? On Feb 2, 10:41 pm, Pedro Junior v.ju.ni.o...@gmail.com wrote: *Seesmic Look is old? * - Pedro Junior 2010/2/2 Lukas Müller webmas...@muellerlukas.de Only old apps can do this. New apps cannot use it. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
[twitter-dev] Re: How Does TwittPic Works ?
oh wow! how do i get in on this sweet UX goodness? is there a form for submitting bribes or is it in-person only? isaiah On Feb 3, 11:49 am, Raffi Krikorian ra...@twitter.com wrote: it will be available publicly soon! On Wed, Feb 3, 2010 at 11:43 AM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, Have you tried it? There is no OAuth flow. I.e., the user types in his Twitter username and password. That's it. If it is indeed using OAuth, does that mean that the background requesting of tokens when you have the Twitter credentials is now available? Meaning, I can also now use it to convert all existing Twitter accounts to OAuth in one fell swoop? On Feb 3, 3:02 pm, Raffi Krikorian ra...@twitter.com wrote: seesmic look, i believe, is using oauth talking to api.twitter.com. On Tue, Feb 2, 2010 at 8:09 PM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, What's going on here? Your credibility is at stake here. You've been telling us in many posts that new apps must use OAuth to get a source attribution, and only old grandfathered apps have source attribution with Basic Auth. On Feb 2, 11:18 pm, Dewald Pretorius dpr...@gmail.com wrote: At first I thought they must have changed the old Seesmic source to Seesmic Look. But no. Here's a recent tweet from Seesmic: http://twitter.com/CathyBrooks/status/8570217879 And here's a recent one from Seesmic Look: http://twitter.com/adamse/status/8565271563 Seesmic Look uses Basic Auth. Does anyone else spot Mt Everest on this level playing field of ours? On Feb 2, 10:41 pm, Pedro Junior v.ju.ni.o...@gmail.com wrote: *Seesmic Look is old? * - Pedro Junior 2010/2/2 Lukas Müller webmas...@muellerlukas.de Only old apps can do this. New apps cannot use it. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop)
How so? What do you think will be the significance of chirp for desktop OAuth? Was there an announcement that I missed? isaiah http://twitter.com/isaiah On Feb 2, 2010, at 10:30 AM, M. Edward (Ed) Borasky wrote: Actually, we'll know the answers at Chirp or before. Chirp is the watershed for Twitter and the developer ecosystem. Time as we know it will be reckoned B.C. (Before Chirp) and A.D. (After Disclosures). ;-) On Tue, Feb 2, 2010 at 9:16 AM, Isaiah Carew isa...@me.com wrote: Leveling the playing field is elephant in the room easy: Immediately ignore the source parameter on all Basic Auth calls. Right now. It's a 5-second coding job. Twitter has announced plans (see @ev's announcement in Dec.) to do almost exactly that come June. Not quite instant gratification, but June is sooner than you think. But two big questions remain: 1. Will Twitter add OAuth additions that allow for alternative credential exchange? (in plain English: username/password on desktop) Raffi has hinted at this previously (source: details ), but few details have emerged. 2. Will Twitter overlook less-than-perfect implementations that improve UX? (i.e. screen scraping the PIN, internal browsers, etc.) So far these practices seem to be flying under the radar in a few clients, but will that change when the big guys enter the game? We'll know the answers in June. It should be fun to watch and make for some lively forum threads. Bring popcorn and stand clear of the flames. ;-) isaiah http://twitter.com/isaiah -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ You're right! Openness about security is really going to hurt us all! Everyone, quick, sh! The bad guys are stupid and will never figure it out if we just keep quiet! OK, sorry, I couldn't resist the bait. ;-) Especially coming from someone that I know appreciates openness. No, I don't actually feel that way. I do actually see your point, but I think the value of discussing threats, so long as the discussions remain unspecific, are probably more valuable than they are detrimental. Also, I think you have it right, that distribution of the source sans keys and the binary with keys is the way to go. I completely agree that it's the obvious practical solution. It's the one that took myself for my OSS OAuth code. However, it also misses the point. The point is that the keys not kept safe in any desktop app, and the challenges are double in open source apps. Up until this point they've probably been safe enough because there have been few targets worth the effort of cracking. I suspect that will change when the clients with many users enter the picture. With many more users there are many more reasons why someone might want to spoof as a specific client. I'd say its a pretty reasonable bet that one of the major desktop clients will be compromised within a year or so of implementing OAuth -- and will probably result in a lot of user frustration. It seems like their will be ample motivation and little to prevent them. Only time will tell, you're free to come and laugh at me if it doesn't happen. Bookmark this email, we'll check back in 18 months. ;-) Isaiah
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
So, in simple language: Twitter's policy is that every user of every open source client register as a new twitter application? Or, have I misinterpreted something? And if so, could you explain further what mean? Thanks, Isaiah what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. isaiah http://twitter.com/isaiah On Jan 30, 2010, at 11:22 AM, Raffi Krikorian wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] OAuth best practice
Although you can find many instances of popular applications that do exactly this, and the precise reasons for it being verboten are definitely arguable and murky at best, the reaction that you'll receive from the OAuth community is likely to be crystal clear, and very negative. I posted an open source app that did this and received this from a founding member of the OAuth committee: ...this approach is specifically one that OAuth is trying to protect users from. The problem is that your app does not (and can not) give users any trust that you (or more importantly, an attacker) are not storing their Twitter credentials without informing them... My personal feelings about the veracity of this statement aside, the tone is pretty clear: you shouldn't do this. isaiah http://twitter.com/isaiah On Jan 17, 2010, at 8:50 AM, eco_bach wrote: I'd like to embed the Twitter OAuth authorization-sign in window WITHIN my application. Is this considered a best practice, or is it always recommended to send the user to a new browser window for the service provider(Twitter in this case) OAuth authentication process?
Re: [twitter-dev] Reinstate 'from app' for Basic Auth desktop apps until OAuth is fixed
The OAuth discussion and call for uses cases has been asked for before by the API team. Specifically 11 months ago by Alex. Here's the link to that discussion: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/655a8425e1e5e045?show_docid=655a8425e1e5e045 It's a good thread that deserves reading as it has contributions from Loren, Blaine, Chris Messina, and Alex. It's pretty much the who's who of desktop/auth/twitter-api. Many of the things that people have put in this thread are some of the same things that were discussed then. Also note that Alex specifically asked for the the community to set up a Wiki about this topic to collect feedback: http://groups.google.com/group/twitter-development-talk/msg/afda4fdf52f78fe3?dmode=source Loren did that and here it is: http://twitter.pbworks.com/oauth-desktop-discussion Just thought I'd post it to this discussion in case someone forgot. isaiah http://twitter.com/isaiah On Jan 11, 2010, at 11:01 PM, Raffi Krikorian wrote: As it stands, developers who have relatively new desktop apps are penalized by having updates from their app say 'from web'. Older Basic Auth desktop clients continue to enjoy a link back to the client web site with a 'from app' link. ... I understand Twitter is trying to force people to use OAuth, but that won't happen in a meaningful way until OAuth is reliable, has a truly usable workflow (PIN method isn't it), and can work well with other services (Twitpic, yfrog, etc). We aren't there yet. i'm trying to gather use cases around OAuth to help it make sense for more people to use it -- as it stands, we are not going to allow the source parameter to be set in new applications unless they come from OAuth. so, please help me out! is the reliability of OAuth an actual concern? do you have a suggestion as to what you would like to see other than the PIN workflow? additionally, we're actively working on a delegation method for integration with other services. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] oAuth new stuff?
i think i've failed to connect and instead i've offended you. i'm sorry, it wasn't my intention. i feel there is a lack of user education going on to explain to users why oauth is actually better for the use i'm just not sure how this is pertinent to anything i wrote. as i said, i want to use oAuth -- i think we all do. you're preaching to the converted. :-) additionally, i understand that simply putting up a dialog box with two text input fields is easier to code than writing software that manipulates a browser, and that is why a lot of applications do that. as i said, i've already gone through the trouble of releasing an open source implementation of oAuth for Mac OS X -- so your hyperbole kind of misses the mark. myself and others have already done the hard work and released open source to help make it easier for the rest to come along. i don't think it's the required effort that is preventing desktop apps from migrating -- it's just the user experience. let me start again. i wanted to show that the current oAuth flow for desktop apps is preventing many desktop apps from moving to oAuth. i did this because your offhand I don't know, response seemed to indicate that the announced changes were not getting much priority in the api. i wanted to help you see the importance of these changes for desktop clients. i'm really excited about the changes. i'm dying to start working on them. i'm committed to releasing an open source solution to them as soon as they come out. i hope you're as excited as i am. if it's unclear on exactly which changes i'm talking about. it's the ones that you mentioned in this post: http://groups.google.com/group/twitter-development-talk/msg/18b38db599f6ad98?hl=en thanks, isaiah On Dec 30, 2009, at 5:53 AM, Raffi Krikorian wrote: i understand that you have to tow the line. i agree with it — at least in principle. i like oauth. i understand it. i *want* to put it in my app. aside from my desktop client, i released an open source oAuth solution: http://thurly.net//5nl yet, of the prominent mac clients (tweetie, twitteriffic, socialite, beak, bluebird, kiwi) only one is currently using oAuth. the reasons are painfully obvious and have been discussed here and elsewhere ad nauseum: http://groups.google.com/group/twitter-development-talk/search?hl=engroup=twitter-development-talkq=oauth+desktopqt_g=Search+this+group honestly, i actually resent the i understand that you have to tow the line statement. i feel there is a lack of user education going on to explain to users why oauth is actually better for the user -- for a list of said reasons, please see http://apiwiki.twitter.com/OAuth+Example+-+Ruby . additionally, i understand that simply putting up a dialog box with two text input fields is easier to code than writing software that manipulates a browser, and that is why a lot of applications do that. as i see it, and having written software against the Twitter APIs (ate our own dogfood), what's missing are the following two things (please add to the list): • when using oauth, a good way to integrate with third party services that also use twitter credentials (yfrog, twitpic, URL shorteners, etc.) -- this is delegation • http://groups.google.com/group/twitter-development-talk/browse_thread/thread/ac563255efcb/951ee32ec9cea3a8?lnk=gstq=delegation#951ee32ec9cea3a8 • http://twitter.com/twitterapi/status/6743938510 • a good workflow for desktop apps -- specifically, desktop applications that have access to a browser. i am -not- talking about rich environments that do not have access to a general purpose browser (set top boxes, game consoles, etc.) what i would rather see, and what i'm interested in fixing, are those two. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Ambiguity with 401 error response code
Are there other error conditions that are similarly ganged up into 401? Or are these two the complete list? Are there other codes that have similarly ganged up error conditions that can only be distinguished by the response text? Are the expected responses (not just the codes) for different conditions documented somewhere? Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah On Dec 29, 2009, at 9:45 AM, Raffi Krikorian wrote: hi eric. yup - you've hit it right on the head. one of the main initiatives in us starting to version our API is so that we can really consolidate and make our error codes consistent. unfortunately, for legacy compatibility reasons, we can't change the second case to have a 402 error and we will have to keep it as a 401. what you could do is parse the response that comes back in the 401, however. in the case that your password is wrong, the error should be Could not authenticate you. for basic auth and OAuth. the second case has an error of Not authorized On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip e...@marcoullier.com wrote: We're trying to build some logic into our data collector and we've been fighting with an issue for a while involving the 401 Unauthorized error code. There are two instances where I can get this response 1) Bad credentials. I try to log in with an invalid username or password. 2) I don't have access to a specific user's private account. The former can be a real problem for a user. I changed my password a few weeks ago and forgot that I was using it for whitelisted REST API access. Querying three times in rapid succession with a bad password causes a temporary lockdown of a user's account. I was querying once per second and locked the account for a five days. This is an account- level issue and the proper way to deal with this from our perspective is to immediately sleep the poller for 30 minutes and send an alert about bad credentials. This is completely different than if someone I'm following has taken their account private. In this case, sleeping for 30 minutes (or any amount of time, really) is overkill. Unless I'm querying for a single person over and over, there's no reason to pause before moving onto the next rule that I'm querying for. Unfortunately, we have no way to disambiguate between the two 401s and we're forced to either lock someone's account (ignoring 401s) or severely reduce their polling efficiency (acting on 401s). Best case would be to break these two error conditions out into separate error codes. Perhaps a 401 for bad credentials and a 402 for lack of authorization for a specific piece of content. Please let know if I've overlooked something that would help me disambiguate the use cases in the current system. Thanks! Eric -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] oAuth new stuff?
and how 'bout that off topic question? a non-silent-treatment sort of answer would be really great -- even if it's i can't tell you or i don't know or that's on a need to know basis and you don't need to know. or you want the truth, you can't handle the truth! or whatever. my biggest concern is that it won't come before the deprecation of oAuth -- and I'll have to implement a pin bases solution in the interim, then rip that out, then implement the new flow if/when it's finally included in the twitter api. if that's the case, then i'm going to need to budget some more $$ for this effort. i'm just looking at what sort of effort and money i'm going to have to spend on this in the next six months. thanks, isaiah On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote: Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah
Re: [twitter-dev] oAuth new stuff?
bummer. i don't mean to be rude, but it sure feels like there is a large gap between the PR announcement a couple weeks ago and the reality on the ground. i'm trying to be patient in letting the info trickle down. i guess i'll ask again in a couple weeks? twiddling thumbs waiting hmmm hmm hmmm until then, my app is limping along with basic auth without attribution. isaiah On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote: i don't know. sorry that i forgot to address your question. On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew isa...@mac.com wrote: and how 'bout that off topic question? a non-silent-treatment sort of answer would be really great -- even if it's i can't tell you or i don't know or that's on a need to know basis and you don't need to know. or you want the truth, you can't handle the truth! or whatever. my biggest concern is that it won't come before the deprecation of oAuth -- and I'll have to implement a pin bases solution in the interim, then rip that out, then implement the new flow if/when it's finally included in the twitter api. if that's the case, then i'm going to need to budget some more $$ for this effort. i'm just looking at what sort of effort and money i'm going to have to spend on this in the next six months. thanks, isaiah On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote: Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] oAuth new stuff?
i understand that you have to tow the line. i agree with it — at least in principle. i like oauth. i understand it. i *want* to put it in my app. aside from my desktop client, i released an open source oAuth solution: http://thurly.net//5nl yet, of the prominent mac clients (tweetie, twitteriffic, socialite, beak, bluebird, kiwi) only one is currently using oAuth. the reasons are painfully obvious and have been discussed here and elsewhere ad nauseum: http://groups.google.com/group/twitter-development-talk/search?hl=engroup=twitter-development-talkq=oauth+desktopqt_g=Search+this+group i suspect that other desktop app devs feel like i do: that the announced oauth addendum was a sea change that looked like a realistic way forward. i was ready to hi-five the first person i saw when i read about it: http://groups.google.com/group/twitter-development-talk/msg/18b38db599f6ad98?hl=en i'm not asking for anything new or different from what has already been announced. i was just hoping for a bit more detail, that's all. isaiah On Dec 29, 2009, at 3:19 PM, Raffi Krikorian wrote: if your application has access to a web browser, then i would strongly suggest that you implement a workflow where your user goes to a twitter.com page -- this workflow is intended to protect the usernames and passwords of Twitter users because they can trust that an unknown app does not have access to their passwords. On Tue, Dec 29, 2009 at 2:31 PM, Isaiah Carew isa...@mac.com wrote: bummer. i don't mean to be rude, but it sure feels like there is a large gap between the PR announcement a couple weeks ago and the reality on the ground. i'm trying to be patient in letting the info trickle down. i guess i'll ask again in a couple weeks? twiddling thumbs waiting hmmm hmm hmmm until then, my app is limping along with basic auth without attribution. isaiah On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote: i don't know. sorry that i forgot to address your question. On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew isa...@mac.com wrote: and how 'bout that off topic question? a non-silent-treatment sort of answer would be really great -- even if it's i can't tell you or i don't know or that's on a need to know basis and you don't need to know. or you want the truth, you can't handle the truth! or whatever. my biggest concern is that it won't come before the deprecation of oAuth -- and I'll have to implement a pin bases solution in the interim, then rip that out, then implement the new flow if/when it's finally included in the twitter api. if that's the case, then i'm going to need to budget some more $$ for this effort. i'm just looking at what sort of effort and money i'm going to have to spend on this in the next six months. thanks, isaiah On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote: Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: A New API For Browserless Apps?
This seems like a dramatic improvement to me. When will Twitter start rolling out support for this, I'd like to be ready with something on github for this as soon as it lands. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Dec 10, 2009, at 5:22 AM, Raffi Krikorian wrote: we're not making any fundamental changes to oauth - your apps should continue to work fine. the changes that we are making involve implementing http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00#section-4. this will allow applications to obtain oauth tokens for a user given the user's username / password. On Thu, Dec 10, 2009 at 1:06 AM, Rich rhyl...@gmail.com wrote: Also if you're going to make changes to oAuth and the way it works currently... please bear in mind many of us already have production apps using oAuth. Maybe you could move the oAuth to versioning to allow us time to move to newer methods as and when you release them? On Dec 9, 7:46 pm, Duane Roelands duane.roela...@gmail.com wrote: If we're talking about replacing the PIN Workflow, then this is a good idea. If we're talking about completely different interfaces for web and desktop apps, I can't see how that's an improvement. Seeing as the Search API is still not in line with the rest of the API, does this mean that we're going to have three disparate incompatible interfaces to juggle? How is that an improvement? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Announcements
From the announcement I read here: http://www.techcrunch.com/2009/12/09/twitter-le-web-2009/ 3) Anyone making OAuth requests to Twitter is soon getting an increased rate limit (10x) – about to launch API for browser-less apps, and starting Basic Auth decprecation in June 2010. Is there more info about this available. I'd love to know more about the API for browser-less apps -- specifically: 1) Will this be appropriate for desktop clients? 2) When? Thanks, isaiah http://twitter.com/isaiah
[twitter-dev] Re: The Difference Between a Twitter Web and Desktop Application
Hi Ryan, Thanks for taking the time. I really appreciate it. I'll be sure to give my feedback. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 12, 2009, at 9:55 AM, Ryan Sarver wrote: Isaiah, We are definitely interested in hearing what type of workflow you would prefer for OAuth-ing desktop applications. We want to make the experience the best it can be and look for your feedback on how we can improve it. Let me start another thread so we can make sure to capture everyone's feedback. Best, Ryan On Sun, Oct 11, 2009 at 12:42 PM, Isaiah supp...@yourhead.com wrote: Like Chris, my app uses a similar UI. I released it as open source several months ago: http://github.com/yourhead/OAuth_ObjC_Test_App It hasn't seen runaway traffic, but it has been downloaded pretty constantly for about three months. There are now also several github clones of the project too. I think it's safe to assume that there are quite a few developers doing the same thing. As we've all seen, there is backlash from users and the media about the OAuth experience: http://twitter.com/gruber/status/4482717284 Judging from the feedback I received, it's safe to say that developers are looking for ways of making this less painful for the Twitter community, i.e. developers are doing this because they believe it will **help** users, not for some malicious reason. Those were definitely my goals. :-) If Twitter thinks this sort of UI is a bad idea, it sure would be nice to get some official feedback about it. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 11, 2009, at 9:28 AM, Abraham Williams wrote: Currently not really. Twitter might start enforcing correct designation at some point though. Abraham On Fri, Sep 25, 2009 at 12:33, cnunciato cnunci...@gmail.com wrote: Hi folks: I'm adding some Twitter integration to a desktop app, and I'm unhappy with the whole copy/paste this PIN into your application experience. In my case, I happen to have a browser instance containing the OAuth authentication process embedded within my desktop app, so it's possible to listen for redirection events that happen inside that browser and respond to them -- but when I mark my Twitter app as a desktop app (on the app-settings screen on Twitter, where it's defined), I'm forced into using the copy-this-PIN approach (because no callback URL can be specified for desktop apps), which, from a user- experience perspective, kinda sucks. I do notice, though, that if I make my app a web app instead, I can specify a callback URL, and have my app watch for redirections to that URL, which works quite well and provides a more seamless user experience. So my question is, is there any disadvanage to marking my installed desktop app a web app on Twitter, so I can take advantage of using a callback URL to provide a better user experience? Is it a violation of terms of use or anything? Any drawbacks at all? Thanks in advance -- Chris -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham http://web608.org/geeks/abraham/blogs/2009/10/03/win-google-wave-invite This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAuth wed desktop feedback
1. What can be improved about the web workflow? I'll leave this one for the web dudes. 2. What can be improved about the desktop workflow? The UX: it's currently very complicated for the user. Much more more complicated than basic auth. Users are unaccustomed to it. Novelty isn't a bonus during authorization. The browser: drop-kicking the user to another app seems egregious. Make it so that this is unnecessary and the UX problem is nearly solved. The assumption: there seems to be an assumption that twitter clients are *not* trusted and the web browser *is* trusted. But the reality is that all of the phishing, scams, and untrusted things that I'm bombarded with daily come in the browser. Please help me to resolve this paradox. 3. What other models of distributed auth do you think we could learn from and what specifically about them? All of the clients for everything that needs authorization on my desktop use a basic-auth-like model: email, ftp, backup services, picture sharing, blogging, well, you get the idea. I'm not saying it's right or wrong, but that is the way it is. I want my app to be part of that ecosystem and not stand out like a sore thumb. Make matching the user experience of other desktop apps your goal. If you can't achieve that goal, then maybe OAuth isn't ready for the desktop. Or perhaps it's more apt to say that the desktop is not ready for OAuth. If you say, it's really no big deal to add this one step, then stop. It **is** a big deal. Every step added is **really** big deal. Really. 4. What could we improve around the materials for integrating OAuth into your application? It's not all the complicated to implement. There's a lot of open source on web in a multitude of languages. If you have manpower to throw around, please work on the UX first. ;-) I'd be happy to contribute to any open source project that helps to achieve this. Count me in. Isaiah
[twitter-dev] Re: OAuth wed desktop feedback
I wouldn't want to speak on Loren's behalf, but it seems to me that your conclusion is similar to Loren's conclusion on this page: http://blog.atebits.com/2009/02/fixing-oauth/ This seems like a reasonable proposal as it's a good stepping stone toward OS. Plus it meets the as easy as basic auth litmus test and would level the playing field between those that must implement OAuth today and those that are grandfathered in to basic auth. Sounds good to me. Where do I sign up? Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 12, 2009, at 2:44 PM, Sebastian wrote: The solution for OAuth on Mobile and Desktop is easy: Allow the app to act as the user agent when authenticating with Twitter when requesting the token and authorizing the app. Let me rewrite this in plain english: let the app ask for login/ password and pass it to twitter. Users don't seem to be worried about providing their credentials to a local app. They do it all the time when configuring basic auth clients, and they do it with 99% of the other client apps they use. Developers are (barely, in most cases) worried about having to store the password, but if they only need it during the initial handshake, then there is nothing to store. All we need is a simple API call where we can trade a login and password for an oauth access token, bypassing the browser. And if you think this will make it less secure, think about a desktop app that, using the current workflow, launches a browser to get the user to approve the app. That browser can be configured to use local proxies, or JS callbacks or any number of mechanisms that let the app capture the authentication credentials. Getting rid of the browser has no negative impact on safety, while giving developers better control of the UX, which gives them more reasons to implement oauth, which does have a positive impact. Anyway, just my two cents. PS: There is nothing right now preventing a mobile or desktop app from bypassing the browser as I'm describing, by acting as a browser and calling the same pages a browser would have presented to the user. On Oct 12, 1:01 pm, Ryan Sarver rsar...@twitter.com wrote: Hey everyone, I wanted to email the list to start gathering some feedback on how we can improve the OAuth workflow. As we have discussed in the past, Basic Auth is going to be deprecated at some point in the future for OAuth and we want to make sure we improve the experience to meet everyone's needs. I am interested in capturing feedback for both the web and desktop workflows. 1. What can be improved about the web workflow? 2. What can be improved about the desktop workflow? 3. What other models of distributed auth do you think we could learn from and what specifically about them? 4. What could we improve around the materials for integrating OAuth into your application? We really appreciate your feedback. Best, Ryan
[twitter-dev] Re: OAuth wed desktop feedback
A good point. Another is that OAuth provides not only authorization, but also authentication. This would enable Twitter to shut down aps that are misbehaving. A feature I'm sure Twitter would like not to give up. I would also take issue with the assumption that third parties would have access to your password. A client that I download, I run, and I delete when I tire of it isn't really a third party. No other human will have access to the password. Put it this way, if I really feel its misbehaving, I can always unplug my machine. ;-) It's important to remember this distinction when web-apps are also being discussed. A web app is different because it does NOT run on your machine, you can NOT shut it down, and other people will definitely have access to the information stored there. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 12, 2009, at 7:36 PM, Brian Smith wrote: Letting a mobile/desktop app grab an OAuth token using the user’s username/password is still helpful because then they can store the token instead of the username/password, which is a big deal when there’s no really secure way to store it. Also, if your mobile phone/ laptop gets stolen, you can still log in via the Twitter website and revoke access from the apps installed on your phone/laptop. If the app just used basic auth then the only way to revoke access would be to change your password. But, whoever stole your phone/laptop could have changed your password first (if the app was using Basic auth), and you’re locked out of your account. So, a way to log in with basic auth and grab a OAuth token would can still be useful. JDG wrote: But it completely subverts the point of OAuth, because it lets a third party have your password. Why even use OAuth in that case?
[twitter-dev] Re: The Difference Between a Twitter Web and Desktop Application
Like Chris, my app uses a similar UI. I released it as open source several months ago: http://github.com/yourhead/OAuth_ObjC_Test_App It hasn't seen runaway traffic, but it has been downloaded pretty constantly for about three months. There are now also several github clones of the project too. I think it's safe to assume that there are quite a few developers doing the same thing. As we've all seen, there is backlash from users and the media about the OAuth experience: http://twitter.com/gruber/status/4482717284 Judging from the feedback I received, it's safe to say that developers are looking for ways of making this less painful for the Twitter community, i.e. developers are doing this because they believe it will **help** users, not for some malicious reason. Those were definitely my goals. :-) If Twitter thinks this sort of UI is a bad idea, it sure would be nice to get some official feedback about it. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Oct 11, 2009, at 9:28 AM, Abraham Williams wrote: Currently not really. Twitter might start enforcing correct designation at some point though. Abraham On Fri, Sep 25, 2009 at 12:33, cnunciato cnunci...@gmail.com wrote: Hi folks: I'm adding some Twitter integration to a desktop app, and I'm unhappy with the whole copy/paste this PIN into your application experience. In my case, I happen to have a browser instance containing the OAuth authentication process embedded within my desktop app, so it's possible to listen for redirection events that happen inside that browser and respond to them -- but when I mark my Twitter app as a desktop app (on the app-settings screen on Twitter, where it's defined), I'm forced into using the copy-this-PIN approach (because no callback URL can be specified for desktop apps), which, from a user- experience perspective, kinda sucks. I do notice, though, that if I make my app a web app instead, I can specify a callback URL, and have my app watch for redirections to that URL, which works quite well and provides a more seamless user experience. So my question is, is there any disadvanage to marking my installed desktop app a web app on Twitter, so I can take advantage of using a callback URL to provide a better user experience? Is it a violation of terms of use or anything? Any drawbacks at all? Thanks in advance -- Chris -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham http://web608.org/geeks/abraham/blogs/2009/10/03/win-google-wave- invite This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Why would it be hosted in your app? Why can't you open Safari? Obviously Safari is *more* trusted. But if you've already installed an untrusted app onto your machine, the untrusted app has enough power to keylog, brute force your keychain (or other password db), send personal info over the net, or any number of other horrible things. Going through a browser fixes many things, but not all of them. And it does come with one huge limitation -- that it makes your user have to jump through yet another hoop to authenticate for what seems (to me, at least) to be security theater. Each hoop always increases your support load and/or limits your customer base -- both costly. I try to avoid costly things with questionable advantages. ;-) The de facto mechanism for dealing with this on the iPhone is to use an integrated WebView. It *is* Safari for all intents and purposes, but it prevents the user from getting booted out to another app and having to find their way back to your app, launch it, and then enter the correct info in the correct spot. It's a huge win for the Ux. And using this same approach on the desktop isn't a half-bad idea either. In case it wasn't already mentioned in this thread there are a couple open source projects that implement oAuth solutions that behave in exactly this way: For iPhone: http://github.com/bengottlieb/Twitter-OAuth-iPhone/ For Mac OS X: http://github.com/yourhead/OAuth_ObjC_Test_App/ Isaiah YourHead Software http://www.yourhead.com On Aug 11, 2009, at 12:58 PM, JDG wrote: Why would it be hosted in your app? Why can't you open Safari? On Tue, Aug 11, 2009 at 13:29, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: Srikanth, By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) That's not a valid use case for faulting the authentication mechanism. The user has already demonstrated an explicit level of trust in the app. That's like saying that if you carelessly trusted someone with your ATM pin number prior to them performing a fraudulent transaction with your ATM card, that it is the ATM machine's fault. It isn't. The problem there is that you trusted a source you shouldn't have. Same thing with executable files containing viruses sent to you via email -- if you choose to run a rogue executable on your computer, it isn't the computer's fault for running it. It is the user's fault for running the executable. NO. With OAuth you are not keying in your password with in the app. No? How is it then that you initially get logged into Twitter -- yes, it might be a Twitter web page, but it is still hosted within your app, right? So whose to say the web page you are viewing is *really* an OAuth page, if you aren't going to trust the app? OAuth doesn't protect from that. Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) You ignored one of my assumptions, which is that passwords aren't stored at all. If basic authentication is used, and passwords are never stored, it doesn't matter if someone steals your iPhone, they cannot get access to your Twitter account. With OAuth, they would still have a degree of access to it, unless I'm missing something. Brad On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote: By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) You are still keying in your password within the app, in code that the developer of this so-called rogue app developed. NO. With OAuth you are not keying in your password with in the app. the developer could still intercept keyboard events and capture your password that way. I have to agree with this particularly for desktop apps (But app store admins catch this.) That said, it seems that the real danger on the iPhone is storing a password, not having the device as a whole password protected, and then losing your device. Someone can then go into your phone, and Twitter related app, and have direct access to your account (which I believe would still be a danger with OAuth tokens). Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
First off, thanks for the heads up and giving us a large lead time. It's what I asked for in a previous email, and even if you never read that email and this isn't a response to me at all. I'll say thanks anyway, because it's great. :-) But, forgive me if I'm off base, but you're saying this change is going to happen just like a switch. One minute the API will behave one way, then next minute the API will behave differently? Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function? After a sudden change any app still using the old behavior is guaranteed to fail. If the app fixes early then it will fail up until the api change. In other words, ALL APPS that use this api call WILL be guaranteed to FAIL for some period of time. That seems like a pretty ugly prospect. Many api temper this sort of change in behavior by adding a new method call or a new argument to the method call. And for some period of time letting both function while marking the old method deprecated, use at the risk of being abandoned without warning at the next update. This lets apps update from one functioning call to another functioning call without users experiencing any downtime. I understand that some changes might need to be rolled in quickly to avert infrastructure disaster or to patch security holes, but with 2 weeks notice, I'm guessing that's not what we're dealing with here. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote: To clarify, since several people have asked: this pending change does NOT mean that pagination is required. You can still attempt to retrieve all IDs in one call, but be aware that this is likely to time out or fail for users with large social graphs. What is defined as large social graphs? -- Arik Fraimovich follow me on twitter: http://twitter.com/arikfr
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
After all this discussion, I'm a bit nervous that I may missed something that needs to be fixed. Does anyone know of a good testcase that will trigger the failures in the OAuthConsumer libs? I've checked POST, seems to work as expected. Tested odd encodings (like spaces and other things that need urlencoding), those seem OK too. What am I missing? Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 30, 2009, at 2:27 PM, jonat...@scribblelive wrote: I may be the only one to be this stupid, but when I looked at my POST request functions, I was appending some parameters like Source, etc. that were common to all requests. But since they weren't there when the signature was generated, we were getting 401 errors as of 7/27. Removing those fixed us right up. --Jonathan On Jul 28, 12:46 am, Duane Roelands duane.roela...@gmail.com wrote: From my experimenting, it appears that posting a tweet is successful if the text contains no spaces. Once you have a space in the tweet, it fails. Researching... On Jul 28, 12:29 am, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I really appreciate your responses. And I definitely understand your point of view now. Paraphrasing: 1. unrelated to basic, oauth is not difficult to implement. i agree. while non-trivial on the desktop simply because no one had done it yet (and released it as OSS), i would agree that it was not especially difficult. 2. passwords can sometime be misused in a cross-site cross-app way. i agree. point taken. especially for the web app world. 3. having twitter included as part of the sign up process feels more integrated. i agree for a web app. and since facebook and flickr do it too, the idiom is well understood. however for a desktop client this is a very abnormal (hopefully just novile?) process -- so i think i would still tend to disagree. thanks again for posting. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 29, 2009, at 8:42 AM, Amitab wrote: On Jul 28, 4:16 pm, Isaiah supp...@yourhead.com wrote: I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. I was merely advocating about OAuth here. I didn't play around with BasicAuth since OAuth was available when I started developing twaller.com. I wanted to respond to comments which said, OAuth is hard to code etc., by saying I didn't feel that way, mainly because I used the library Twitter4J. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? I think there is a difference. I find passwords messy because if someone wants to misuse them, they can potentially misuse them for other websites beyond twitter. Many people including myself have similar usernames and exactly the same password in multiple websites. So if I accidently leak a password, and someone uses that to login a bank website and make a financial transaction, that will not look very good. Oauth token's are limited to Twitter use. At the moment, i am not encrypting it in my database. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. I meant the process of going to Twitter for a login makes me feel that my application is integrated with them. As oppossed to merely saying, please supply your Twitter name and password to my website. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). That is a very valuable
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
* We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. More testing is always a good goal if feasible. However, no spec is perfectly complete, thus no spec is perfectly stable. And no implementation is perfect, thus no implementation is perfectly stable. Suggesting that your implementation be perfect next time as a solution to your current instability might not be the best takeaway here. It seems to me that the takeaway is that instability exists and our (twitter and the dev community) system for dealing with it was too fragile. Being constructive: Perhaps an API release mechanism that can withstand a bit of instability is worth investigating. * We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. While I don't disagree at all, why wait until after? While the number of apps that use the twitter api is many, the number of libraries is few. Perhaps a private list to their primary maintainers is worth investigation. Even if it was just the primaries from the list of libraries on your site: http://apiwiki.twitter.com/OAuth-Examples They might have given you a little warning of the likely panic. Perhaps not enough time to change, but at least enough time to soften the blow with some information. We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks. Not to let this post get too technical -- but my current released code ( OAuth_ObjC_Test_App ) seems to work (e.g. it checks and posts without any problems that I notice), however I'm not entirely sure what corner cases might trigger the failures. If anyone has an idea of what regressions to run, I'd appreciate any info. Thanks. Isaiah
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). These jerks are everywhere now, and they're the real deal. They have a lot of cash and a lot of patience to think of new ways to exploit your resources to their own end. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. I've noticed this too. From an outsider layperson's point of view is seems as though we're pushing every authorization request through a single doorway. My hope is that it's more a lack of my understanding, than anything else. Right? Right?!?! ;-) Thanks for hearing my devil's advocate argument. Don't feel compelled to respond. I don't *need* answers, just curious, that's all. Isaiah
[twitter-dev] Re: need help with OAuth library usage in cocoa app
My example was built right as the pin code method was invented/ implemented in the API. So my example still uses the Browser method that doesn't require a pin code. If you go to your application settings page in twitter and set your Application Type to be Browser you should be good to go. As I understand it the PIN code was invented to help clients that couldn't detect if the browser had been sent to the success callback URL. However, my example doesn't have this issue. My example embeds the browser and communicates directly with it to determine when the callback URL is sent. This technique obviates the need for the pin code. I like to think of my example as a hybrid app -- neither purely a desktop client nor really a web app -- but a little bit of both in the right places. ;-) I've considered adding the pin code, but it seemed to further complicate an already challenging UI without adding any value. If you have any other issues with the example code, please feel free to email me directly. I'd be happy to help out. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 24, 2009, at 12:04 AM, Fares Farhan wrote: Dear Twitter developers, First, I apologize if I misplace the question. I've cloned Isaiah's git repository of his AOuth implementation from http://github.com/yourhead/OAuth_ObjC_Test_App/tree/master but I experienced an issue that after the web sheet closed, there is no place that I can put the PIN retrieved from the authentication result, or anywhere in the code that I need to pass the oauth_verifier parameter along with other params. the debugger said that ther is Operation could not be completed. (NSURLErrorDomain error -1012.) Thank you in advance for any response, Cheers, Fares
[twitter-dev] Re: need help with OAuth library usage in cocoa app
Thank you for your prompt reply Isaiah, No worries. Glad to help out. Thank you also for the offer of emailing you directly, but I think your code is also precious for other newbie like me who want to know more about this OAuth thing :) It wasn't so easy to figure out a nice way to do this stuff. I figured it would be a good thing to share. Glad it's helped. About changing application type to be Browser, then there is Callback URL: box that I have to fill, which I have no idea what do I have to fill in there. But I tried it anyway, and same result. The callback URL can be any URL you like. After a successful authorization this is the URL that's loaded. You should specify the URL both in the twitter app setup and also as a constant in the YHTwitter.m file on line 25: #define kYHOAuthTwitterCallbackSuccessURL @http://twitter.com/; Through the browser delegate methods the client will know that the callback URL was reached and the authorization was granted by the user. This triggers the example app to close the browser window and save the OAuth info to the keychain. Although I would imagine you would want to change it to your own web site for practical reasons, leaving it as http://twitter.com/ should *work* at least for testing purposes. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 24, 2009, at 1:06 PM, Fares Farhan wrote: Thank you for your prompt reply Isaiah, Thank you also for the offer of emailing you directly, but I think your code is also precious for other newbie like me who want to know more about this OAuth thing :) About changing application type to be Browser, then there is Callback URL: box that I have to fill, which I have no idea what do I have to fill in there. But I tried it anyway, and same result. Fares On Jul 24, 10:58 pm, Isaiah supp...@yourhead.com wrote: My example was built right as the pin code method was invented/ implemented in the API. So my example still uses the Browser method that doesn't require a pin code. If you go to your application settings page in twitter and set your Application Type to be Browser you should be good to go. As I understand it the PIN code was invented to help clients that couldn't detect if the browser had been sent to the success callback URL. However, my example doesn't have this issue. My example embeds the browser and communicates directly with it to determine when the callback URL is sent. This technique obviates the need for the pin code. I like to think of my example as a hybrid app -- neither purely a desktop client nor really a web app -- but a little bit of both in the right places. ;-) I've considered adding the pin code, but it seemed to further complicate an already challenging UI without adding any value. If you have any other issues with the example code, please feel free to email me directly. I'd be happy to help out. Isaiah YourHead Software supp...@yourhead.comhttp://www.yourhead.com On Jul 24, 2009, at 12:04 AM, Fares Farhan wrote: Dear Twitter developers, First, I apologize if I misplace the question. I've cloned Isaiah's git repository of his AOuth implementation from http://github.com/yourhead/OAuth_ObjC_Test_App/tree/master but I experienced an issue that after the web sheet closed, there is no place that I can put the PIN retrieved from the authentication result, or anywhere in the code that I need to pass the oauth_verifier parameter along with other params. the debugger said that ther is Operation could not be completed. (NSURLErrorDomain error -1012.) Thank you in advance for any response, Cheers, Fares
[twitter-dev] Re: Use Twitter for login oauth/authenticate method
I'm still not sure I understand the option. Is there any reason why someone would choose NOT to check this box currently? Also, if you are in the process of redesigning the auth page, could I make a request: Could there be a super-lightweight version for mobile? No images, no scripts, inline css, fluid width, etc. Maybe it already exists and I'm doing something wrong. Feel free to point me in the right direction too. ;-) Isaiah On Jul 1, 2009, at 7:50 AM, Matt Sanford wrote: Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the /oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the Use Twitter for login option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: off topic
yep, just me, thanks, isaiah p.s. subject changed to protect the on-topic folks. @isaiah for more. ;-) On Jul 1, 2009, at 12:27 PM, Neil Ellis wrote: On a completely separate note, your website is stunning, did you design it yourself? If not may I ask who were your designers. All the best Neil http://www.peepwl.com On 1 Jul 2009, at 20:22, Support wrote: Matt, Thanks for weighing in and hopefully taming this snarl. As the person who might have posed the question originally, I figured I at least owed a bit of constructive critique. What can we change about OAuth that would make this better? 1) User experience - it's been echoed a number of times in this board, so i won't beat the dead horse... much...but basic auth *is* much simpler for the user. The reason is obvious: oauth requires a browser. In many platforms (especially mobile) that's a painful burden. The PIN code seems to be ignoring the elephant in the room. It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps. You've made the pill even more effective, but so bitter that your patients can't swallow it. Providing a scheme that does not require a browser is an obvious way to cut this gordian knot. 2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle. There are obvious technical challenges, however the larger problem is that in OSS there is no way to define each application. There will be many binaries for different platforms and people will fork it on github just because they can. You cannot identify each of these variants as the same when they could be different. And that places a burden on the user experience. When a user grants access to application x -- what does that mean exactly? Just that binary? Just this release? Only from a specific trusted company? How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second? I personally don't see an obvious solution to this problem. It seems to be a UI challenge and a technical challenge. In cases like that it seems prudent to question your goals and check feasibility. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like GoodApp needs you to re-approve us). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for easy. I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote: But that's
[twitter-dev] Birdfeed App
Just curious if anyone knows if the new Birdfeed ipone app that's just been released today uses OAuth 1.0a Pin flow, the other OAuth flow, or basic auth. Anyone know? Isaiah
