One benefit of running an app within Twitter.com is that it will eliminate the need for the OAuth dance. That is the complex exchange that goes on between a website and the Twitter API when the user logs into Twitter through the website. This communication is necessary to deliver a set of authorization keys that can be used by the site to get the Twitter account information for the user.
You’ve seen this dance before, even if you didn’t realize exactly what was happening. You are on a website, and see a button that says 
. Clicking that button takes you to a Twitter controlled page where you can give permission for the site that sent you there to operate on your behalf. When you then give permission, you are sent back to the site to continue where you left off. This whole procedure confuses both the user and the developer who has to implement it. One way of measuring how big a hurdle this is for Twitter API developers is the fact that my tutorial on using OAuth is the number one visited page on this site. It gets about 30% of all of my site traffic, even though it was written 2 years ago. There is no doubt that the OAuth dance is a pain for everyone involved.
As part of making it possible for developers to run apps within tweets, Twitter will have the chance to streamline this whole process. The Twitter page will already know who the logged in user is. It is just a matter of making this available to the application code running within the tweet.
There are several possible to ways to implement an API that passes this info. I can’t predict exactly how this will be done, but I am sure it will have to be done. Think about what would happen otherwise. A user who is logged into Twitter sees an app in a tweet, and tries to interact with it. Will Twitter then send that user to another sign-in page to log in again? That makes no sense. There will have to be a transparent way to let the app discover who the current user is.
Explicit authorization by the user will still be necessary before the app can change the user’s Twitter account or tweet on their behalf, but the UI for that will also have to be handled by Twitter. Otherwise the clean and consistent experience Twitter is striving for will not be achieved. I handle UI issues like this all the time in the website apps I build for clients. I’m sure Twitter can figure out how to make it happen. They have no choice.
Putting these implementation details aside, the real take away is that apps within tweets will be easier to build and easier for users to interact with. That has to be good for everyone involved, and result in increased adoption and production of Twitter apps.
