[twitter-dev] Re: Will requesting DM access now disable xAuth for my app?
Arnaud, Absolutely true! We'll encourage (by that I mean force) users to re- authorize once they get our new version. That exercise could alleviate the massive support headache of Why can't I load my messages?. Please roll out the force_login and screen_name parameters to http://api.twitter.com/oauth/authorize, and we'll get this put to bed! Andrew Stone Twitter / @twittelator http://www.stone.com http://j.mp/twitpad http://j.mp/twitpro On May 31, 10:42 am, Arnaud Meunier arn...@twitter.com wrote: Hey Andrew, All your old Read Read/Write user_tokens will continue to work, but they'll lose their ability to read direct messages. Arnaud / @rno http://twitter.com/rno On Mon, May 30, 2011 at 3:22 AM, janole s...@mobileways.de wrote: Hi Andrew, many thanks for your feedback from me, too! ;-) I didn't dare to make the switch for my xAuth app yet ... I'm just wondering if the actual switch to the new xAuth permission policy next month will have any impact on this? Is xAuth as such still supposed to work, but simply returning RW tokens then? Will the old xAuth tokens continue to work after the switch has been made end of July? Ole On May 29, 6:49 pm, twittelator and...@stone.com wrote: I poured a 4-shot breve latte just in case, flipped the switch athttps:// dev.twitter.com/apps, and was delighted when: - shipping Twittelators already deployed can use and continue to get valid RW XAUTH Tokens - those XAUTH tokens still work - New RWDM tokens are correctly given to new in-house builds of Twittelator So, I can totally relate to the feeling of Am I about to hose 1 million users? but, especially with the enhancements due this week from Twitter, I think we can all make a smooth transition to the new flow. On May 27, 11:31 pm, Ed Finkler funkat...@gmail.com wrote: Fellers, For testing as we prep our apps for the switch to PIN-based auth, I'd like to change the default access level to Read, Write, Private Message. However, I'm concerned this will disable xAuth for existing users immediately, rather than once we hit June 30. Can I do this, or should I register a new application? Or do I have other options? Thanks, -Ed -- 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 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: Will requesting DM access now disable xAuth for my app?
I poured a 4-shot breve latte just in case, flipped the switch at https://dev.twitter.com/apps, and was delighted when: - shipping Twittelators already deployed can use and continue to get valid RW XAUTH Tokens - those XAUTH tokens still work - New RWDM tokens are correctly given to new in-house builds of Twittelator So, I can totally relate to the feeling of Am I about to hose 1 million users? but, especially with the enhancements due this week from Twitter, I think we can all make a smooth transition to the new flow. On May 27, 11:31 pm, Ed Finkler funkat...@gmail.com wrote: Fellers, For testing as we prep our apps for the switch to PIN-based auth, I'd like to change the default access level to Read, Write, Private Message. However, I'm concerned this will disable xAuth for existing users immediately, rather than once we hit June 30. Can I do this, or should I register a new application? Or do I have other options? Thanks, -Ed -- 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: Problema
Poderia ser possível que o que o Twitter Search analisador não trata de bem com diacríticos Portugues? #UniãoDoTwitterSegueEuTeSigoDeVolta The Twitter search component was acquired from Summarize a few years back, and it's been a great piece of tech - but it's alas not very native and it probably won't be long before a more integrated and even more historical search can become part of the API. On Apr 29, 5:42 pm, Rafael Cavalcante Silva rafahu...@hotmail.com wrote: Estou escrevendo pra vocês porque há uns dias não estão aparecendo meus tweets nos temas, aqueles 10 temas que são os mais citados por país e outros temas como #UniãoDoTwitterSegueEuTeSigoDeVolta etc. Não estão aparecendo. Eu escrevo o tema, mas meu tweet não aparece no tema. Por favor, ajudem. Desde já, agradeço. -- 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] Re: Snowflake: An update and some very important information
It's kind of cool that Craig has been programming professionally longer than some people on this list have even been alive! I've thought about the problem, and at least came up with a catchy name for it to go with the crises of yore: Bitpocalypse. Since Twittelator uses the JSON library YAJL, my approach will be to correctly populate the id with an unsigned long long created from the id_str field at the point of data arrival. Then it's done and no other code needs changing. But I'll find out Friday! On Oct 19, 12:27 pm, Craig Hockenberry craig.hockenbe...@gmail.com wrote: This still gives you some API legacy that you need to maintain, but it's a much cleaner approach than what is currently being proposed. -ch On Oct 19, 10:39 am, Tom van der Woerdt i...@tvdw.eu wrote: I wouldn't blame this on JSON, because it's not JSON that has the problems, but JavaScript. All of my Objective-C apps that communicate use JSON as well, and they don't have the limitation. The issue does not apply to XML either - there's no type specification in XML. As far as I know, this issue will only cause trouble for a few applications that work with JavaScript and depend on the IDs a lot. My suggestion to solve this issue would be to introduce an additional parameter (just like include_rts, just with a different name) that turns all IDs into strings. No extra fields, just an additional optional parameter. Won't cause trouble for the applications that can't parse it and requires minimal implementation effort for developers. I hope I'm not too late with my suggestion :-) Tom On 10/19/10 7:10 PM, Craig Hockenberry wrote: This approach feels wrong to me. The red flag is the duplication of data within the payload: in 30+ years of professional development, I've never seen that work out well. The root of the problem is that you've chosen to deliver data in a format (JSON) that can't support integers with a value greater than 2^53 bits. And some of your data uses 2^64 bits. The result is that you're working around the problem in a language by using a string. Avoiding the root problem will encumber you with legacy that you'll regret later. Look at your proposed solution from a different point-of-view: say you have a language that can't handle Unicode well (e.g. BASIC or Ruby.) Would you solve this problem by adding another field called text_ascii? text: @themattharris hey how are things in K benhavn?. text_ascii: @themattharris hey how are things in Kobenhavn?. Seems silly, yet that is exactly what you're doing for Javascript and long integers. A part of this legacy in your payload is future confusion for developers. Someone new to the Twitter API is going to be confused as to why your ID values have both numeric and string representations. And smart developers are going to lean towards the numeric representation: * 8 bytes of storage for 10765432100123456789 instead of 20 bytes. * Faster sorting (less data to compare.) * Correct sorting: 011 and 10 have different order depending on whether you're sorting the string or numeric representation. They'll eventually pay the price for choosing incorrectly. Every ID in the API is going to need documentation as a result. For example, are place IDs affected by this change? And what about the IDs returned by the Search API? (there's no mention of since_id_str and max_id_str above.) Losing consistency with the XML format is also a problem. Unless you're planning on adding _str elements to the XML payload, you're presenting developers with a one-way street. A consumer of JSON id_str can't easily change the format of data they want to consume. In my mind, you really only have two good choices at this point: 1) Limit Snowflake's ID space to 2^53 bits. Easier for developers, harder for Twitter. 2) Make all Twitter IDs into strings. Easier for Twitter, harder for developers. The second choice is obviously more disruptive, but if you really need the ID space, it's the right one. Even if it means I need to make major changes to my code. On Oct 18, 5:19 pm, Matt Harris thematthar...@twitter.com wrote: Last week you may remember Twitter planned to enable the new Status ID generator - 'Snowflake' but didn't. The purpose of this email is to explain the reason why this didn't happen, what we are doing about it, and what the new release plan is. So what is Snowflake? -- Snowflake is a service we will be using to generate unique Tweet IDs. These Tweet IDs are unique 64bit unsigned integers, which, instead of being sequential like the current IDs, are based on time. The full ID is composed of a timestamp, a worker number, and a sequence number. The problem - Before launch it came to our attention that some programming languages
[twitter-dev] Re: OAuth Rate Limit Increase - Not seeing it
I reported this bug yesterday. Instead of making that extra call, why not look at the response headers which come back with each API ACCESS - you'll get the info you need: X-Ratelimit-Limit = 150; X-Ratelimit-Remaining = 133; X-Ratelimit-Reset = 1267576025; Andrew Stone Twitter / @twittelator http://www.stone.com got iPhone? http://j.mp/twitpro http://j.mp/tweettv-app On Mar 2, 11:47 am, eclipsed4utoo ryanalford...@gmail.com wrote: I thought that the OAuth Rate Limit went up to 350? I am still getting 150. Here is the returned XML from my request tohttp://api.twitter.com/1/account/rate_limit_status.xml ?xml version=1.0 encoding=UTF-8? hash reset-time type=datetime2010-03-02T19:42:28+00:00/reset-time hourly-limit type=integer150/hourly-limit reset-time-in-seconds type=integer1267558948/reset-time-in- seconds remaining-hits type=integer150/remaining-hits /hash I am using OAuth and using the new version of the REST API. What else do I need to do?
[twitter-dev] Re: Introduce yourself!
They call me @twittelator probably because I wrote Twittelator Pro Free, full featured iPhone twitter clients that shipped on day 1 of the AppStore 2 years ago. I got started on the iPhone 22 years ago as one of the first third party developers for Steve Job's company 'NeXT' - and we're using the same, though evolved, SDK and language (objectiveC) on the iPhone and iPad today. I'm looking forward to CHIRP and meeting you all, and I have a special connection to the Palace of Fine Arts. In 1992, John Perry Barlow and I invited a bunch of our outrageous psychedelic friends and members of the NeXT community to a rave we hosted there. I think that was the last one they let happen there, but it was quite memorable! My phone was tapped for two years after that, but it was worth it. I'd love feature parity with Twitter web - like a flag to home timeline that would include RT's. I'd like access to xAUTH like some other vendors already have, to have Apple Push Notification Service built in to twitter's device delivery options, and while I'm fantasizing, a link to our app in the ad-space! http://stone.com So. Who are you, what do you do, what have you built, and what feature do you most want to see added?
[twitter-dev] Re: Lists API for Subscriptions
To get the lists a user is subscribed to: :user/lists/memberships.:format Andrew Stone Twitter / @twittelator http://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:52 pm, Eric Woodward e...@nambu.com wrote: Anyone seeing an issue with a method to get a list of a user's list subscriptions? The following: curl -u ejwc:[password] http://twitter.com/ejwc/lists.xml; only returns the three test lists that I have created, while the same URL on Twitter's website: https://twitter.com/ejwc/lists returns my three test lists, and the 5+ lists I am following. Any suggestions? I have only just started getting a response for the API methods in the last day or so and only getting familiar with them. Any help would be appreciated. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Lists API for Subscriptions
Whoops - what I meant to say was: :user//lists/subscriptions.:format will get the lists a user has subscribed to Andrew Stone Twitter / @twittelator http://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:52 pm, Eric Woodward e...@nambu.com wrote: Anyone seeing an issue with a method to get a list of a user's list subscriptions? The following: curl -u ejwc:[password] http://twitter.com/ejwc/lists.xml; only returns the three test lists that I have created, while the same URL on Twitter's website: https://twitter.com/ejwc/lists returns my three test lists, and the 5+ lists I am following. Any suggestions? I have only just started getting a response for the API methods in the last day or so and only getting familiar with them. Any help would be appreciated. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Subscribed Lists
:user/lists/subscriptions.:format gets the lists that the user has subscribed to. Andrew Stone Twitter / @twittelator http://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:00 am, David Neubauer davidneubauer.gro...@gmail.com wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Early developer preview: Retweeting API
I've spent eleven days of reTweet contemplation and these thoughts percolated up: 1. twitter as a phenomena has been driven bottom up by the users 2. forcing new paradigms on our users will result in general unhappiness 3. presenting new paradigms as options to our users will allow happy migration Therefore, May I present to you, VART's : Value Added ReTweets. OK that's a stinky name but I see the value of allowing users to do the instant, no-thought-required new-style RT as well as the old- fashioned edit, trim, comment and send. I think it will take a while for users to grok that the auto retweet method preserves authorship, and a good UI will tag it as such and allow the value of the new api to be perceived. Maybe an additional parameter to statuses/update that this is indeed what's going on? @twittelator / http://stone.com On Aug 13, 2:52 pm, Marcel Molina mar...@twitter.com wrote: Retweeting has become one of the cultural conventions of the Twitter experience. It's yet another example of Twitter's users discovering innovative ways to use the service. We dig it. So soon it's going to become a natively supported feature on twitter.com. It's looking like we're only weeks away from being ready to launch it on our end. We wanted to show the community of platform developers the API we've cooked up for retweeting so those who want to support it in their applications would have enough time to have it ready by launch day. We were planning on exposing a way for developers to create a retweet, recognize retweets in your timeline and display them distinctively amongst other tweets. We've also got APIs for several retweet timelines: retweets you've created, retweets the users you're following have created, and your tweets that have been retweeted by others. - Creating Retweets The API documentation for creating retweets can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet Reminder: Making requests to /statuses/retweet won't work yet as the feature has not launched. - Consuming Retweets in the Timeline 1) Retweets in the new home timeline We don't want to break existing apps that don't add retweeting support or create a confusing experience for that app's users. So the /statuses/friends_timeline API resource will remain unchanged--i.e. retweets will *not* appear in it. For those who *do* want to support retweets, we are adding a new (more aptly named) /statuses/home_timeline resource. This *will* include retweets. The /statuses/friends_timeline API resource will continue to be supported in version 1 of the API. In version 2 it will go away and be fully replaced by /statuses/home_timeline. The API documentation for the home timeline, which includes retweets, can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t... Take a look at the example payload in the documentation. The original tweet that was retweeted Thanks appears in the timeline. Notice the embedded retweet_details element. It contains the user who created the retweet as well as the date and time the retweet occurred. 2) Retweeted by me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... 3) Retweeted to me timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... 4) My tweets, retweetedhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... Reminder: Making requests to any of these timelines won't work yet as the feature has not launched. UI considerations: -- Here are some early draft design mockups of how retweets might appear on the Twitter website (don't be surprised if it doesn't look exactly like this). They are presented just as an example of how retweets can be differentiated visually. http://s.twimg.com/retweet-dev-mocks-7-aug-09.png Things to note: 1) It was important for us that retweets are easily differentiated visually from regular tweets. If someone you follow retweets a tweet, the original tweet will appear in your timeline whether you follow the author of the original tweet or not, just as it currently does when users use the RT convention. Seeing a tweet in your timeline from someone you don't follow without being told it was shared from someone you *do* follow could be confusing. So we're encouraging developers to be mindful of this confusion and make retweets stand out visually from regular tweets. 2) The retweeted tweet shows the username of the first of your followers to retweet it. If other's subsequently retweet the same tweet, the retweet should only appear once in a user's timeline That's it for now. We'll be sending out more updates as we get closer to launching. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: WWDC Twitter developer meetup at Twitter HQ: RSVP!
I'd like to throw out: Wednesday June 10th at 5 PM at Twitter HQ because: 1. classes are over by then 2. monday folks are too buzzed 3. tuesday is usually awards and pizza 4. beer bash on thursday 5. people have left town by friday On May 26, 4:07 pm, Manton Reece man...@gmail.com wrote: I'd agree with Craig -- pick any day except Monday and Friday, and most people can probably make it work. Afternoon is good. Thanks for organizing this! On May 21, 4:18 pm, Alex Payne a...@twitter.com wrote: Hi all, There's great crossover between Twitter API developers and Mac/iPhone developers. Andrew Stone, developer of Twittelator Pro, suggested that we all get together during WWDC and coordinate around the Apple Push Notification Service and other issues of mutual interest. Twitter's offices are just a few blocks from Moscone, so it should be easy for any interested coders to make it over here. Please RSVP with a reply to this thread and let us know what dates and times work for you. Andrew was thinking early one morning, but not being much of a morning person, I'd prefer something later in the day. We'll let group consensus decide. Thanks, and hope to see you in early June. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
