[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 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 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 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 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 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] Twitter's Mobile OAUTH authorize landing page defects
The Twittelator iOS twitter client team has done our best to make the user experience of the new OAUTH Webflow as clean and user friendly as possible. And, for everything we can control, it's feeling good. Of course, there's one thing we have no control over: the http://api.twitter.com/oauth/authorize page - and yet, that's at the heart of the User's login experience! Defect #1: On iOS devices, the "Username or email" field, invariably attempts to Capitalize the first character of your username. Just extra and useless friction for the end user. I'd bet 90% of twitternames begin lowercase. Defect #2: Likewise, auto-correct is on for the the "Username or email" field - but who uses a plain english word? More friction. The fix is trivial I believe: Defect #3: Forgot your password button is close enough to authorize that manly fingers might inadvertently tap it instead of the Authorize button. Because the keyboard may animate up and down, the buttons are sliding up and down as you go to tap. Perhaps it could be to the right of the password field above "No Thanks". Defect #4: Authorize button ignores first click sometimes and simply initiates a keyboard [may be iPad only] Enter your username, enter your password, tap the dismiss keyboard button. Now, tap Authorize. I see the keyboard come up, no other action. You have to tap the Authorize button again. Something about putting away the keyboard looses focus on the webpage so that the first tap is ignored by the Authorize button. Anyway these can be addressed soon? Believe me, it really is the little things that make the biggest differences! -- 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 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 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 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. > > > >
[twitter-dev] Re: Lat,long, vs long/lat
Think of the mathematics coordinate system of X, Y [ longitude,
latitude ]
On Aug 13, 9:55 am, Dan wrote:
> Why is it that in most of the API, geo-co-ordinates are represented as
> lat,long?
>
> e.g.http://api.twitter.com/1/statuses/show/21059379505.json
>
> ...geo":{"type":"Point","coordinates":[44.6994873,-73.4529124]}...
> (like most of the world does it)
>
> but in the places API it is long,lat?
>
> e.g.
>
> http://api.twitter.com/1/geo/id/881e03b2b43d3810.json
>
> {"geometry":{"type":"Point","coordinates":[-73.452852,44.698943]}...
>
> This is very confusing!
>
> Cheers
>
> Dan
[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 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 > > > > 2010-03-02T19:42:28+00:00 > 150 > 1267558948 seconds> > 150 > > > 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: 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" 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 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: 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 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
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 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: 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 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 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 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
