Thanks for the info Matt. It is much appreciated. However, you guys really need to stop doing this type of stuff. The war on client apps is getting a bit out of control. They grow the twitter userbase, and dev's helped make twitter what it is and sustain its growth by offering many different ways to connect on various devices, with different UI's that lots of users like, and in places and ways it may not be available otherwise. And some users effected by these clients going down, will never use twitter again since their favorite app or site is now gone, they would just rather not mess with getting a new one and move on.
You dont have to control the market to capitalize on control of the user base. If more effort was spent on an iAds type program like for Twitters case could be TwitAds for developers to integrate, then you would be making much more in the long run. Or even adding in ads to the API streams with revenue sharing for clients. Then just have a good standard guideline for UI, data access and usage, then boom, no more stress of loosing control. No more having to buy Tweetdeck for 50 million because it controls too much. Just add in revenue sharing from ads and clear guidelines for clients, then your problem is solved. But the way it is being looked out now is not sustainable or realistic in todays market from my perspective. Developers are scared to death all the time because we know there will be something new (like this) every other month or so and we are just waiting for that final one that cuts our legs out from under us completely. I dont think Twitter should see it as taking away, but the potential it has to add many more users to the system, and if they look at revenue differently than just twitter controlling all ads and clients do their own, they would see a much higher spike in revenue and clients would have a standard system they could use for their revenue stream as well. Then if you need to do quality control thats understandable, just lay out the requirements in simple terms, show some examples, make them realistic, then we all make money and twitter continues it growth with the help of Dev's. But without the wealth and diversity of client apps, you will see slower growth, and less user engagement. On May 18, 7:11 pm, themattharris <thematthar...@twitter.com> wrote: > Hey everyone, > > Thank you for all the feedback on the list, email and through Tweets. > We've been responding throughout the day to many of the Tweets but > wanted to group the questions together and respond here as well. > > > Two weeks is not enough time to implement a web OAuth flow and have the app > > approved. We need an extension. > > We’ve heard your feedback on this list, privately and through Tweets > about this. Based on this feedback we are going to extend the > enforcement deadline by two weeks. > > **** This means we'll enforce the new permission the week beginning > the 14th June 2011. **** > > This should provide enough time for you to make the change and have > your application approved by your chosen platform’s app store. > > > Will Twitter's own applications also go through the OAuth web flow? > > We’re taking this step to give more clarity and control to users about > the access a third-party application has to their account. The way > users interact with Twitter’s clients is not expected to change. > > Applications who wish to access a user’s DMs will need to update their > application permission and incorporate the OAuth web flow if they > don’t already. If an application does not need access to DMs it will > not need to make any changes. > > > Why will you not grandfather existing applications into DM access? > > Grandfathering all existing read/write tokens assumes they all wanted > access to DMs. The feedback we’ve had from users and developers tells > us otherwise. We want to give users the opportunity to make an > informed choice. > > > What if the client using xAuth has no browser and therefore cannot go > > through OAuth? > > For single user applications and scripts we provide the 'My Access > Token' page of the application details. To ensure the 'My Access > Token' is correct it is important the app owner revokes their access > before change the permission level of the app. If you do not do this, > the 'My Access Token' will not be regenerated with the new permission. > This revoke action is only needed by you, the owner of the > application. Remember Read/Write applications can still send direct > messages. > > > When you activate the new permission, will all Read and Read/Write > > user_tokens issued to third-party applications lose their ability to read > > direct messages? > > Existing tokens are unaffected by any change to the application > permission level. If you change your application to R/W/DM all future > authorizations will be for that permission. When a user re-authorizes, > their existing token will be updated to the current application > permission level. Access to DMs will be enforced on 14th June 2011 if > the user_token wasn't authorised as for R/W/DM. > > > What if I want to request a different level of access for my application > > instead of the one my application is registered with? > > You can do this now by using the x_auth_access_type parameter during > the request_token phase. Using this parameter you can request a read > or a read/write token even if your application is registered for read/ > write/direct messages. > > More information on this method is in our developer documentation: > http://dev.twitter.com/doc/post/oauth/request_token > > > Why are permissions attached to the user token? > > Permissions are attached to the user token to ensure an application > only has the access a user has authorised. If permissions were not > attached to the user token an application would be able to change the > level of access they have without the user’s knowledge. If you tie the > permissions to the application each user token would need to be > invalidated whenever an application’s permissions are changed. > > > Users already gave their permission for apps to access private messages, > > why are you making us, and them, reauthorize? > > The purpose of the re-authorization is to ensure both users and > developers know the level of access requested. Re-authorization allows > a user to make a more informed decision about the access an > application has requested. > > We hope these responses answer your questions. Please continue to send > us your feedback about the permission model and what you would like to > see it offer. > > Best, > @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
