Twitter and the DM ish

Twitter uses an authentication system called oAuth (oauth.net) to allow third party apps authenticate users on the platform. The strong point of oAuth is to prevent users from sharing their username and password with the third party site/app. The user is therefore redirected to twitter, puts his/her username/password, twitter generates a token (an encoded string of the allowed permissions for the authenticating app) and sends this, as well as redirect the user, back to the authenticating site/app. Technically, it is more complex than that though.

Before now, there are two permission levels for third party apps on twitter. Read and write. Read means access to 'viewing' tweets, dms and streams while write means ability to post, delete, update and the like. As an app creator, when registering your app on twitter, you specify what permission you want for your app, i.e read, write or both. Ofcourse most apps request both. With the new permission model, twitter introduced a new permission level - Direct Message. This means any application that wants to be able to access and modify dms must request for that permission (the developer page https:// dev.twitter.com/apps is dedicated for that). But that's not all. Existing users of the app must also reauthenticate their account on the app to get a new token that has the dm permission. In other words, the user either deletes his account or sign out, then reauthenticates again so that he/she is taken back to twitter to login again. At twitter he is told the authenticating app wants read, write and dm permissions. He allows (or rejects), adds his username/password and is taken back to the app with the new permission token. His DM now becomes available on the app and everyone lives happily there after.

But not yet.

The limitation with oAuth is that it works best for web apps as users are easily redirected to authenticate on the provider site and back again to the web app. It is practically impossible to redirect user back to a native desktop or mobile application. Desktop apps still have their ways but it is more difficult with mobile apps especially ones with limited native api priviledge like Java. To tackle this, Twitter has a PIN method that generates a pin when the user successfully authenticates on twitter via the app. The user then copies the pin and enters it back at the application. To make things even simpler, twitter also has xAuth. XAuth doesnt redirect users to authenticate on twitter's site. It allows the app collect the user's username and password and exchange it for the necessary token. And this is what most mobile apps like Snaptu and Nimbuzz have been using.

And now, back to the new permission model. The new permission model only allows reauthentication via oAuth.
"To ensure users know that an application is receiving access to their direct message we are also restricting this permission to the OAuth authorize web flow only. This means applications which uses xAuth and want to access direct messages must send a user through the full OAuth flow" - http://groups.google.com/group/twitter-api-announce/browse_thread/thread/e954...
What this means is that applications using the xAuth authentication method won't be able to access DMs. They can still send DMs though. And that explains why many people have been having difficulty with their DM.

Solution?

For xAuth apps, the only way, from the discussion group, is that the app must find a way to reauthenticate users via oAuth. This means redirecting the user to enter his login details on twitter and find a way to transfer hm/her back to the app, thus killing the original model for xAuth. But ofcourse, the app would have modified its permission level (from http://dev.twitter.com/apps) to include the dm permission. Except there is therefore some other work around, if your application uses xAuth, without it taking you through the browser based oAuth flow, you may not have access to your dms :/