Deprecation of the email parameter for users/show
Doug Williams
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/thread/ac80b4fdf8eb742a/692b27b8ebd07268?lnk=gst&q=email+parameter#692b27b8ebd07268
2. http://code.google.com/p/twitter-api/issues/detail?id=353
Thanks,
Doug Williams
Twitter API Support
http://twitter.com/dougw
John Sampson
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 Sampson
http://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.
>
> 2.http://code.google.com/p/twitter-api/issues/detail?id=353
Todd Sampson
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.
>
> 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.
>
Tim Rosenblatt
Doug Williams
the crew [1].
1. http://code.google.com/p/twitter-api/issues/detail?id=416
Doug Williams
Twitter API Support
http://twitter.com/dougw
