[twitter-dev] Re: Feedback wanted on Twitter + iOS
Ability to access DMs, with a system-supplied modal dialog (a la the Location Services dialog), would be ideal. Steve -- 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
[twitter-dev] Re: A new permission level
If you're a developer who got bit in the ass by this move by Twitter, and need to migrate your application from using xAuth to using OAuth, I have a sample project which shows you how to obtain authorization for a user. It's Objective-C, but the concepts should be applicable to whatever language you're coding in. You can check it out at https://github.com/amazingsyco/oauthery. Steve On May 18, 5: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
[twitter-dev] Re: consistency and ecosystem opportunities
Twitter continues to make hostile and aggressive moves to alienate the third-party developers who helped make it the platform it is now. Today it's third party Twitter clients. Tomorrow it'll be URL shorteners and image/video hosts. Next it'll be analytics and ads and who knows what else. Maybe you guys should spend some time improving the core of the service (uptime, reliability, bug fixes, etc.) rather than ingressing on the work of the thousands of developers who made Twitter an exciting place to be. Steve -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] MGTwitterEngine with OAuth and XAuth support
Hey everyone, I'm one of the collaborators on the MGTwitterEngine project for Mac and iPhone developers. We've finished our initial implementation of OAuth and XAuth support within MGTwitterEngine. This uses the OAuthConsumer framework to handle the business end of OAuth, meaning that there are only a couple new MGTwitterEngine APIs you need to use (and we've got a wiki guide for migrating to OAuth). We expect most users of the framework to want to use XAuth to obtain an access token, so we have a convenience API for handling that (of course, you'll need to obtain the opt-in from Twitter). After getting XAuth access, it shouldn't take more than a half hour to get set up to obtain your access token and start sending requests. We're also planning on releasing a new version of MGTwitterEngine with support for some new APIs and bug fixes, as well as OAuth. We're hoping to get this out by WWDC, or at least before the OAuth deadline. We're aware of the buffer needed for App Store approval, so we'll be trying to finish this up ASAP. You can grab the code from the project page here: http://github.com/mattgemmell/MGTwitterEngine/ You can read the migration guide here: http://wiki.github.com/mattgemmell/MGTwitterEngine/migrating-from-basic-auth-to-oauthxauth Feedback is always welcome. If you have any issues, please file them in the project issue tracker here: http://github.com/mattgemmell/MGTwitterEngine/issues Now stop using basic auth already. Thanks, Steve
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Especially on mobile devices, it's significantly faster to sort tweets by comparing the long long representation of an ID rather than by the date. It's also more accurate, as two tweets that come in at the exact same second will still be sorted in the correct order. Steve On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] [ANN] OAuthery - Mac developer tool for logging into Twitter OAuth manually
Hey everyone, I just released a tool for Mac OS X called OAuthery. It allows you to manually obtain an access token using the PIN-based workflow. This is especially useful if you're using OAuth in a script or a bot. You enter your consumer key and consumer secret, and the system will obtain a request token. You authorize the application in the browser, then enter the PIN number into the application. Then it will fetch the access token and display it to you, which you can then copy into your script. It includes full source code, so developers targeting the Mac or iPhone platforms can see a reference implementation of the login workflow using the OAuthConsumer framework. You can download a precompiled application or the source over at GitHub: http://github.com/amazingsyco/oauthery Feedback always welcome! Thanks, Steve
[twitter-dev] Twitpocalypse and yajl
For those who didn't survive to the post-twitpocalyptic world thanks to YAJL, give this patch a shot. http://gist.github.com/129033
