Seconding this.
On Apr 3, 4:51 am, Todd Sampson <toddsampson2...@gmail.com> wrote: > If you are going to deprecate this method, can you at least return a > user not found error as opposed to returning user "twitter.com/show"? > I have received numerous complaints that users we lookup are being > assigned to user "show" and their "TonsOfWeed.com" website -- which > for obvious reasons is not the way to handle a deprecated function. > > - Todd > > On Apr 2, 9:00 pm, John Sampson <j...@johnasampson.com> wrote: > > > Thank you for the clarity and for putting greater detail on the > > deprecation of user/show (find by email). I completely agree to > > Twitter wanting to protect its user's privacy. I'd like to think that > > the value created by whitelisted applications is far greater than the > > pain being caused by non-whitelisted api users. I hope that a speedy > > solution can be found for these spammers. > > > Much of my concern I'd previously mentioned on ticket #353 > > -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. > > > To be clear, this does break the Twitter integration with our Firefox > > extension (which I consider the most valuable portion of our ext), > > surfacing information for user with screen name "show" rather than the > > person you are connecting with keyed off email. Additionally, > > workflow need be re-authored in our other apps that have leveraged > > this method to date. > > > Hoping I can be of further assistance in returning this method to the > > production API. > > > John Sampsonhttp://zentact.com > > > On Apr 2, 5:59 pm, Doug Williams <d...@twitter.com> wrote: > > > > For a few days, the users/show method offered look up based on a > > > user's email address. So short-lived was its documented availability > > > that we removed it without much fanfare. This thread [1] has mention > > > of this deprecation. > > > > Recently, there has been quite a bit of discussion on this feature's > > > reinstatement on and off the list. Issue 353 [2] covers this request. > > > > The use of the method was largely as intended; people were discovering > > > account connections based email addresses. This made integration with > > > other networks and applications trivial. However, there was a > > > significant amount of traffic that was using this parameter for evil. > > > In either case, the adoption was minimal (we did not receive a > > > complaint that the deprecation completely broke someone's > > > application). The rationale for deprecation was to protect our users' > > > privacy. > > > > We do realize the large amount of value that this parameter creates > > > for application developers. However at this time, we are working to > > > identify a solution for the spammers that caused the deprecation. One > > > suggestion is to grant trusted applications access to this parameter. > > > Since our answer to trusting applications is OAuth and it is still in > > > beta, we will not be able to devote the resources necessary to bring > > > this parameter back at this time. > > > > If you are developing an application that could benefit from an > > > email-based lookup, please star the issue [2] accordingly. > > > > 1.http://groups.google.com/group/twitter-development-talk/browse_thread... > > > 2.http://code.google.com/p/twitter-api/issues/detail?id=353 > > > > Thanks, > > > Doug Williams > > > Twitter API Supporthttp://twitter.com/dougw
