Re: [twitter-dev] oAuth new stuff?
> > i wanted to show that the current oAuth flow for desktop apps is preventing > many desktop apps from moving to oAuth. > ah - yes - in this, we are in total agreement. while the pin workflow, and using protocol handlers work (protocol handlers probably better than pin workflows), there still is a huge area of UX innovation that can occur and user education that can occur to make this better. > 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. > the "i don't know" is just that - technically, its a relatively simple thing, but i know, internally, we are working on the method by which to release, the terms around the release, etc. that, bundled with it being the end of 2009 and everybody is on vacation, makes getting things out relatively challenging. but solely from a process stand point. > 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. > totally! -- 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=en&group=twitter-development-talk&q=oauth+desktop&qt_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=gst&q=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] oAuth new stuff?
i think they both technically are great solutions - protocol handlers work _great_ on platforms that support them. and i think it makes for a great UX. > On Wed, Dec 30, 2009 at 07:53, Raffi Krikorian wrote: > >> 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.) > > > You don't think either the PIN flow or applications registering as protocol > handlers work well enough? > > -- > Abraham Williams | Blog | http://the.hackerconundrum.com > Project | Intersect | http://intersect.labs.poseurtech.com > Hacker | http://abrah.am | http://twitter.com/abraham > This email is: [ ] shareable [x] ask first [ ] private. > Sent from Madison, WI, United States -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] oAuth new stuff?
On Wed, Dec 30, 2009 at 07:53, Raffi Krikorian wrote: > 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.) You don't think either the PIN flow or applications registering as protocol handlers work well enough? -- Abraham Williams | Blog | http://the.hackerconundrum.com Project | Intersect | http://intersect.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Madison, WI, United States
Re: [twitter-dev] oAuth new stuff?
Yoono desktop application (and firefox add-on) is using OAuth too. 2009/12/30 Isaiah > > 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=en&group=twitter-development-talk&q=oauth+desktop&qt_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 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? > > > > > > > > > > > > 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 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] 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=en&group=twitter-development-talk&q=oauth+desktop&qt_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=gst&q=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] 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=en&group=twitter-development-talk&q=oauth+desktop&qt_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 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? > > > > > > 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 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] oAuth new stuff?
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.compage -- 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 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? > > > > > > 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 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] 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? 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 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 don't know. sorry that i forgot to address your question. On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew 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
[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
