Deprecation of source parameter registration

0 views
Skip to first unread message

Doug Williams

unread,
Apr 8, 2009, 10:14:52 PM4/8/09
to Twitter Development Talk, twitter-ap...@googlegroups.com
Applications wishing to append the "from [MyApp]" to tweets have traditionally been able to register for a source parameter. This application is then manually approved, and specified in a header parameter (named: source) during the HTTP request. When OAuth is used for API authentication, we can implicitly determine which application is updating on a user's behalf. This allows us to use the application's name as the source parameter and bypass the messy registration and authorization cycle.

Beginning late this week or early next week, application developers will no longer be able to request API source parameters. Instead, new source parameters will only be available for OAuth applications, and will be managed by the developer through the registration and management interface (http://twitter.com/oauth_clients).

Three key points:
1) We ARE NOT deprecating Basic Authentication in the near term. We ARE trying to reduce the API team's administrative load.
2) We are trying to encourage OAuth adoption.
3) Just for kicks, I'll restate #1: Basic Authentication will continue to work as it currently does. Registered source parameters will continue to work as they currently do.

The FAQ [1] has been updated to reflect this change.

1. http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9DappendedtoupdatessentfrommyAPIapplication

Thanks,
Doug Williams
Twitter API Support
http://twitter.com/dougw

Alex

unread,
Apr 8, 2009, 11:15:04 PM4/8/09
to Twitter Development Talk
When you say that you can implicitly determine the application, does
that mean that source parameters will become mandatory and anything
posting via the API will be automatically assigned one?
> 1.http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9Dap...

Damon P. Cortesi

unread,
Apr 9, 2009, 1:12:36 AM4/9/09
to Twitter Development Talk
Doug,

What about applications that do not post through the API, but still
want a source parameter? Or is this type of behavior going to be
discouraged in the future?

As an example, TweetStats does not require you log in to retrieve the
data necessary, but I do have "promotional" links on the site that
append the source parameter so it appears to come "from TweetStats".
It's an extra bit of link juice (although I include a link in the
tweet anyway, not all applications may) and it also allows me to get
an idea of how many people use that link.

Will this type of source specification still be allowed? Or in the
future will I just need to sign up for OAuth and use that source
parameter even if my application doesn't need auth?

Thanks,

dpc
> 1.http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9Dap...

Doug Williams

unread,
Apr 9, 2009, 1:38:04 AM4/9/09
to twitter-deve...@googlegroups.com
We will certainly retain the administrative ability to create source parameters when circumstances warrant an exception. But on the whole, we will prefer that applications use OAuth to create and manage their communication with the site, even in the scenario you mentioned.


Doug Williams
Twitter API Support
http://twitter.com/dougw


Mobasoft

unread,
Apr 9, 2009, 8:22:09 AM4/9/09
to Twitter Development Talk
When I discovered that Twitter used the name from my recetly created
app via OAuth, I was pleased.
While the turn-around time for manual approval was great, I think that
using the data which we've already supplied through the creation of a
new OAuth app is the right way to go.

Keep up the good work.

Marco Kaiser

unread,
Apr 9, 2009, 8:53:26 AM4/9/09
to twitter-deve...@googlegroups.com
Why are you deprecating a very important feature for the basic auth method while your OAuth support is still in beta?

The last official statement I read about Twitter and OAuth was that it went public, but is still considered beta. Also, if I did not miss an announcement, you were not yet encouraging developers to release OAuth based stuff - has this changed?



2009/4/9 Mobasoft <Moba...@gmail.com>

Doug Williams

unread,
Apr 9, 2009, 1:01:27 PM4/9/09
to twitter-deve...@googlegroups.com
Marco,
OAuth is still in public beta. We are growing comfortable with the software's abilty and even see early OAuth inclusion in consumer facing sites. Nothing has changed in our stance toward driving releases because we are still planning some UX improvements. However we all write software because we want users to enjoy our work and understand that some developers have OAuth-based applications ready to ship and support.

There is still time to get a source parameter through the manual registration process so developers that see the need should register now. We do not anticipate the layover from deprecation to the full release of OAuth to be very large which makes us confident that this deprecation is a safe move.


Doug Williams
Twitter API Support
http://twitter.com/dougw


Chad Etzel

unread,
Apr 9, 2009, 1:19:53 PM4/9/09
to twitter-deve...@googlegroups.com
On a personal note, even though I have created a few "toy" apps that
use OAuth to get a feel for it, I am holding off integrating OAuth
into several of my longstanding apps until the last possible minute
b/c of the current Beta instabilities (tho few, they still exist), and
the recent twitter server availability issues. For Basic Auth stuff,
down time or time-outs are fairly tolerable and just involve a retry
of the request. For OAuth stuff, having a time-out or connection blip
in the middle of the token transaction process wreaks havoc on the
process flow and UX for the user and interacting with an app (which
has happened to me more than a few times).

> We do not anticipate the layover from deprecation to the full release of OAuth to be very
> large

Does that mean you have a roadmap or estimated timeframe for taking
OAuth out of Beta and into "full production mode"? I think it would
be helpful for all involved to be clued into such information.

-Chad

Sam Johnston

unread,
Apr 12, 2009, 10:39:19 AM4/12/09
to Twitter Development Talk
Hi Doug,

On Apr 9, 4:14 am, Doug Williams <d...@twitter.com> wrote:
>
> Beginning late this week or early next week, application developers will no
> longer be able to request API source parameters. Instead, new source
> parameters will only be available for OAuth applications, and will be
> managed by the developer through the registration and management interface (http://twitter.com/oauth_clients).

This seems a little premature don't you think? The source parameter is
important for marketing applications as well as gauging popularity -
OAuth is both still in beta and unsupported by many clients/
applications.

I've just started developing a Twitter app using python-twitter that
is to run on Google AppEngine, but it will be some time after the next
release before we have OAuth support (and even then it's dependent on
a "major overhaul of the HTTP layer")[1].

Sam

1. http://code.google.com/p/python-twitter/issues/detail?id=37&q=oauth#c4

Doug Williams

unread,
Apr 14, 2009, 7:28:02 PM4/14/09
to Twitter Development Talk
We've finished the removal of this functionality from the site so
third-party registration is no longer supported. If you feel that you
have an extraordinary need for explicit source parameter registration,
please email a...@twitter.com. Include why you need to register an
application manually and why OAuth will not work in your case.

Thanks,
Doug Williams
Twitter API Support
http://twitter.com/dougw

On Apr 12, 7:39 am, Sam Johnston <s...@samj.net> wrote:
> Hi Doug,
>
> On Apr 9, 4:14 am, Doug Williams <d...@twitter.com> wrote:
>
>
>
> > Beginning late this week or early next week, application developers will no
> > longer be able to request APIsourceparameters. Instead, newsource
> > parameters will only be available for OAuth applications, and will be
> > managed by the developer through the registration and management interface (http://twitter.com/oauth_clients).
>
> This seems a little premature don't you think? Thesourceparameter is
Reply all
Reply to author
Forward
0 new messages