[twitter-dev] Twitter OAuth Timestamps
I have confirmed a problem with xAuth/OAUth that I believe resides within Twitter OAuth implementation that has been a thorn in our side for a while. I say *believe* because I do not claim to know for sure, thus this post. I assume no one at Twitter will be inclined to do me any favours, but please answer for the sake of the users in general, and other developers in here that do a better job of not publicly expressing their opinions of what Twitter has been doing to its ecosystem. If a user's desktop time is off by a significant margin, say 30m, we have confirmed that a valid username/password via an xAuth request will fail. This has been very painful to track down since those working on Nambu tend to have the desktop time set correctly, and only a handful users complain legitimately, with credibility. This tweet started us on to a solution: http://twitter.com/imhassan/status/14639986090. It is not affecting just Nambu. I cant find anything in the OAuth specs to suggest this comparison to the actual time should take place, so I assume Twitter is just going ahead and comparing the submitted timestamp to the actual time, and rejecting the request (for perhaps a good reason), or it is a bug. We are getting a 401 on a valid request with an inaccurate timestamp. This issue is hinted at here: http://weblog.bluedonkey.org/?p=959. Anyway, we are putting a workaround in place, so if no one at Twitter responds, no worries, Nambu will work going forward. Other developers, be aware that this issue exists. This is very annoying to me because users with inaccurate time settings have tried to verify their accounts in Nambu, failed, and then use the official Twitter application for OSX (aka Tweetie), which works because it is still on HTTP Basic authentication, and declared Nambu to be broken. Twitter, please clarify which part of the process is indeed broken, and what you expect to see regarding timestamps on your end. I assume that by the time Twitter for OSX is updated to use xAuth you will have put a solution in place for this, or will at some point soon afterward as users complain. It would be nice if you outlined that solution for the rest of us when the time comes, so perhaps we can improve on what we have come up with. I apologize in advance if I missed something obvious in the docs somewhere. I am not an expert on OAuth by any means, and have not studied this issue per se. I have only been trying to resolve the issue for us to move on to something more important. Our OAuth implementation works fine otherwise. Well, as well as the rest of the Twitter API works, anyway. Cheers. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Twitter OAuth Timestamps
Thanks. I did look through the archives before posting but did not find anything. I will look harder next time. I still don't see where in the OAuth specifications it says this comparison is necessary, but I will continue to look around. --ejw Eric Woodward Email: e...@nambu.com On May 25, 5:49 pm, Brian Smith br...@briansmith.org wrote: This is known and expected behavior. There have been other threads about it in the last couple of weeks. If you get a 401 response, you should compare the Date header of Twitter's response to the current system time. If it is significantly off then you should warn the user so they can fix it and/or calculate the difference and add that offset to all your timestamps. More details are available in the mailing list archive. Regards, Brian -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter- development-t...@googlegroups.com] On Behalf Of Eric Woodward Sent: Tuesday, May 25, 2010 7:40 PM To: Twitter Development Talk Subject: [twitter-dev] Twitter OAuth Timestamps I have confirmed a problem with xAuth/OAUth that I believe resides within Twitter OAuth implementation that has been a thorn in our side for a while. I say *believe* because I do not claim to know for sure, thus this post. I assume no one at Twitter will be inclined to do me any favours, but please answer for the sake of the users in general, and other developers in here that do a better job of not publicly expressing their opinions of what Twitter has been doing to its ecosystem. If a user's desktop time is off by a significant margin, say 30m, we have confirmed that a valid username/password via an xAuth request will fail. This has been very painful to track down since those working on Nambu tend to have the desktop time set correctly, and only a handful users complain legitimately, with credibility. This tweet started us on to a solution: http://twitter.com/imhassan/status/14639986090. It is not affecting just Nambu. I cant find anything in the OAuth specs to suggest this comparison to the actual time should take place, so I assume Twitter is just going ahead and comparing the submitted timestamp to the actual time, and rejecting the request (for perhaps a good reason), or it is a bug. We are getting a 401 on a valid request with an inaccurate timestamp. This issue is hinted at here:http://weblog.bluedonkey.org/?p=959. Anyway, we are putting a workaround in place, so if no one at Twitter responds, no worries, Nambu will work going forward. Other developers, be aware that this issue exists. This is very annoying to me because users with inaccurate time settings have tried to verify their accounts in Nambu, failed, and then use the official Twitter application for OSX (aka Tweetie), which works because it is still on HTTP Basic authentication, and declared Nambu to be broken. Twitter, please clarify which part of the process is indeed broken, and what you expect to see regarding timestamps on your end. I assume that by the time Twitter for OSX is updated to use xAuth you will have put a solution in place for this, or will at some point soon afterward as users complain. It would be nice if you outlined that solution for the rest of us when the time comes, so perhaps we can improve on what we have come up with. I apologize in advance if I missed something obvious in the docs somewhere. I am not an expert on OAuth by any means, and have not studied this issue per se. I have only been trying to resolve the issue for us to move on to something more important. Our OAuth implementation works fine otherwise. Well, as well as the rest of the Twitter API works, anyway. Cheers. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
At this point I am not why anyone that cares enough to be in this group is surprised. It is clear that Twitter is going to take *everything* for themselves. I don't understand why anyone would continue to develop on Twitter's platform as anything more than a hobby. First it was us (Twitter clients) and now it is the ad platforms' turn. Next it will be somebody else. Lots of us enjoy developing for its own sake, and that is what Twitter is now: a feature you add to something else, or a hobby activity. Time we all just faced up to it. --ejw Eric Woodward Email: e...@nambu.com On May 24, 9:23 am, Mo maur...@moluv.com wrote: You guys couldn't have hinted about this to me at the developer meetup or at Chirp before I built up a team? Thanks.
[twitter-dev] Re: What's happening with Tweetie for Mac
Ryan, Thanks for clarifying, finally, at least. Rebranded Twitter or not, Tweetie as owned and developed by Twitter basically reinforces and confirms everything that we posted on the Nambu blog this morning: Twitter will take anything significant built around Twitter for itself, 100%. Twitter is now officially developing native applications on three platforms: iPhone OS, OSX and Blackberry, all free. Simply brutal. But I am not nearly affected as the iPhone developers. They should be rightfully livid that Twitter moved to wipe them out and take all advertising revenue (iAd and other stuff) on the iPhone and iPad for themselves rather than share it, as almost all other platforms do. Pretty sad. Make no mistake, Twitter for iPhone will take all significant market share, and there is nothing any of the developers there that have done great work can do about it. If you do not see this, you do not understand the basics of business. Making Tweetie free is pretty brutal as well, but only because Twitter is doing it. Everyone else should be put on notice that you will be next, as we have been. Mr. Wilson and Twitter, with these moves, and have basically told everyone of competence that they must accept their development efforts as only ending up as a nice lifestyle business. Anything more, and Twitter will move to take it from you, simple as that. --ejw Eric Woodward Email: e...@nambuc.om On Apr 12, 10:39 am, Michael Macasek mich...@oneforty.com wrote: Ryan, Great news thanks for the update! Jesse, Well said. On Apr 12, 10:40 am, Ryan Sarver rsar...@twitter.com wrote: One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Twitter buying Tweetie
I am also happy for Loren, he deserves it based purely on the quality of his product. I would like some clarification on the intended future of Tweetie for OS X. The plans for the iPhone and iPad have been made very very clear: stay away. Please clarify the plans for OS X. But at this point I don't really expect a response, but I need to ask. --ejw Eric Woodward Email: e...@nambu.com -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] API Limit of 150 is Obsolete
I will come straight to the point: we need to an increase to the API limit to properly implement Twitter within a desktop client application given the addition of: 1) three retweets timelines; 2) checking the account's saved searches; and 3) up to 10-20 Twitter Lists timelines. Twitter Lists alone are causing real problems if a user follows more than 5 or so. We cant poll Twitter List subscriptions with one API call that combines them altogether, which we could then split apart client-side with some attached meta-data. That alone would have been a big help, and without it we are left polling each List as if it was a separate timeline, since that is what they are. Implementing proper Lists management is a non-starter within this limit, so is regular confirmation of a relationship between two users when asked for by the user (on Lists or search results). There is simply a lot of stuff I cannot do properly that is standard on twitter.com, all because I am subject to the API limit while twitter.com is not. Users simply do not understand this distinction in possibilities. I would like to formally ask on behalf of all client developers that the API limit increase to 250, from 150, for all applications whether they use OAuth or HTTP Basic Authentication. We are simply not able to implement Twitter properly within a limit of 150, but dont need a lot more, only another 100-200 API calls or so. If Twitter can even technically contemplate a 10x API limit increase to 1,500 for OAuth applications, surely an increase to 250 based on the addition of core features like official retweets and Lists is a reasonable request. A limit of 150 is simply obsolete, and has been for a long time. I do not want to wait for the UX repairs around OAuth for desktop applications, and I dont like being forced into OAuth sooner than we are ready just because we need the extra API hits just to do basic features properly. And besides, that was announced as two weeks away three weeks ago. I dont want to wait any longer. I want to properly implement the basics, like Lists polling, now. This is a considered email because I care about the quality of our Twitter implementation and I care about the Twitter ecosystem. I would appreciate a considered reply. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Blocked Users on Lists
How is it possible no one from Twitter would respond to this? --ejw Eric Woodward Email: e...@nambu.com On Nov 16, 10:03 am, Eric Woodward e...@nambu.com wrote: So, unless it has changed or I messed up test queries, users that I have blocked still appear in Lists timelines when I request these Lists from my authenticated account. Can someone else confirm or deny this for me? Twitter, please confirm whether this is the desired behaviour going forward, or a bug, or a development item yet to be completed. If need be I will have to implement this client-side with a list of blocked IDs, but no sense doing that if the API will do it at some point, obviously. As Lists exist now it is impossible to follow a List that contains someone you simply dont want to hear from. If this is a noisy prominent well-known person it detracts from almost all Lists in defined vertical segments. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Blocked Users on Lists
So, unless it has changed or I messed up test queries, users that I have blocked still appear in Lists timelines when I request these Lists from my authenticated account. Can someone else confirm or deny this for me? Twitter, please confirm whether this is the desired behaviour going forward, or a bug, or a development item yet to be completed. If need be I will have to implement this client-side with a list of blocked IDs, but no sense doing that if the API will do it at some point, obviously. As Lists exist now it is impossible to follow a List that contains someone you simply dont want to hear from. If this is a noisy prominent well-known person it detracts from almost all Lists in defined vertical segments. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Lists API for Subscriptions
Thanks for that. It would be great to combine them and reflect ownership in the response data set. This requires two API calls for what will be requested each time to show both sets together, which you on twitter.com. I assume others will tend to show both sets at the same time as well. --ejw Eric Woodward Email: e...@nambu.com On Oct 31, 3:01 pm, twittelator and...@stone.com wrote: Whoops - what I meant to say was: :user//lists/subscriptions.:format will get the lists a user has subscribed to Andrew Stone Twitter / @twittelatorhttp://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] Lists API for Subscriptions
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: Twitter Lists: /user/list/members.xml returning only 20 at a time
Rich, I think you answered your own question there, the first one anyway. I would not expect a real answer to the second one. --ejw Eric Woodward Email: e...@nambu.com On Oct 26, 2:30 am, Rich rhyl...@gmail.com wrote: Seriously have we got a two tier dev system now, can we all have access to the API please? On Oct 24, 10:18 pm, Dave Briccetti da...@davebsoft.com wrote: How can I retrieve more than 20 at a time? ?cursor=-1count=200 has no effect
[twitter-dev] Lists API
So, what is the plan for releasing the Lists API, if there is one? It is well known that selected people have access to them while the rest of us do not, which is creating a problem with users. Is there a plan to release these APIs to everyone soon? Please respond. I am only asking. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: Lists API
Hmm. Ok, thats is obviously fair enough, in theory. You obviously need to test and debug something with a subset of traffic. But Lists are operational now on twitter.com which serves millions, so it seems you are well down that road, yet no API, no draft API methods to review like we have for retweets, nothing. Services contact me to integrate services they developed on top of Lists meaning they have had access to the API for weeks, or more. Basically, you are rolling out critical platform improvements that many of us don't have access to. I am not sure what the point of being a Twitter developer is if you dont give us all fair access to key elements of the service. You have also created a small nightmare for those us that implemented a version of Lists/Groups that is now starting to confuse users. Basically, from what has been going on from the bit.ly transition to suggested users lists to preferential access to stream APIs to free advertising/endorsements for some to now giving access to the Lists API to selected people, I could write a book on how to not manage an ecosystem using Twitter as the prime example. Please please at least give us a draft API to review for Lists as you have done for Rewteets so we can at least *plan* a transition from our own Groups implementations, or how we will coordinate the two features based on the API methods. You have people building services on opt of the Lists API and pitching me to include it in Nambu, so it is obviously a lot further along you are letting on here. --ejw Eric Woodward Email: e...@nambu.com On Oct 15, 4:19 pm, Marcel Molina mar...@twitter.com wrote: We are rolling it out to a small set of users incrementally so that we can load test and find bugs. We've been working on the API documentation and will be rolling it out gradually. On Thu, Oct 15, 2009 at 4:10 PM, Eric Woodward e...@nambu.com wrote: So, what is the plan for releasing the Lists API, if there is one? It is well known that selected people have access to them while the rest of us do not, which is creating a problem with users. Is there a plan to release these APIs to everyone soon? Please respond. I am only asking. --ejw Eric Woodward Email: e...@nambu.com -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Preview Access to Lists API?
So, I am hearing from a few people that they have advanced preview access to the Lists API, the feature that was announced recently. It is a cool thing to see a steady stream of feature additions in the pipeline. I look forward to adding Lists to Nambu. First, please confirm that this is true, that some people have access to these APIs while the rest of us don't even know what the feature set actually is, and what we will be possible via the API. Second, if true, can Twitter please at least publish these APIs as beta specifications as you have done with the retweet APIs, so the rest of us second-tier developers can at least see what they will *exactly* be? With that we can at least prepare implementations. I all really want to know is what lists will *exactly* be as offered by the Twitter API. At the moment many of us that are not blessed services dont even know what they are, let alone have a chance to already build features on top of them, while those are that are blessed are already working on them. --ejw Eric Woodward Email: e...@nambu.com
