Re: [twitter-dev] Re: Switching Application Type to Browser
On Jun 23, 2011, at 20:14 , Victoria wrote: If I change Application Type to Browser (on the https://dev.twitter.com/apps/edit/ page), will this negatively affect the xAuth process currently used in the production version of my Twitter client? Victoria, Only Twitter or an experiment with an xAuth enabled application can answer this question. It could go either way. That said, I expect that the authorization paths, due to the different routes, are independent for xAuth and the OAuth path. (I believe the app type is really a choice between three-legged browser OAuth and PIN OAuth.) Twitter folks need to answer this question. Good luck. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe -- 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
Re: [twitter-dev] Switching Application Type to Browser
On Jun 23, 2011, at 02:51 , Victoria wrote: I assume I just need to switch my real app's type to Browser now, but I wanted to check—will the users of the old version of my app run into any problems if I do this? As I understand it, the authorization tokens that exist do not change. They will just stop being authorized to send or read direct messages. IOW, old tokens are being limited in a new way. Your new version will be able to switch to new tokens to return a user's capabilities to what they once had. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe -- 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
Re: [twitter-dev] Consumer Key and Secret Bug
On Jun 5, 2011, at 10:07 , iDeviceDesigns wrote: So for example if I use the normal count which is only 20 everything works just fine, then if I log 100 everything works fine for around two refreshes then it locks the keys up which means if I had the app out for production and wanted to change something and this happens ALL my customers will be affected . I am completely confused as to why this would happen besides there must be a bug in the API and the consumer key, secrets Dear iDeviceDesigns, As you don't mention which route you are using, I can only make a guess. I make almost every query to Twitter using the maximum count from iOS (200 tweets w/ user info and entities). On startup I also go get the most recent 800+ tweets. My access tokens, as advertised, never expire. I am heavier user of the API, as you claim to use it, than you are and I do not see your reported behavior. Hence, without more specific data, I suggest that the problem is in your code. Anon, Andrew P.S. Most APIs that service hundreds of thousands of accesses every hour, as Twitter's APIs do, are really unlikely to exhibit this kind of bug. It would hit every client and web site. We would hear about it on this list. Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe -- 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
Re: [twitter-dev] DM enforcement date has been extended to the end of June
On May 27, 2011, at 18:39 , Matt Harris wrote: This makes the new enforcement date Thursday, June 30th, 2011. Thank you Mr. Harris and the Twitter development and policy team team. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho When you can't imagine how things are going to change, that doesn't mean that nothing will change. It means that things will change in ways that are unimaginable. Bruce Sterling, January 02, 2009 -- 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
Re: [twitter-dev] Will requesting DM access now disable xAuth for my app?
On May 28, 2011, at 00:31 , Ed Finkler wrote: Can I do this, or should I register a new application? Or do I have other options? Just create a test account and use it. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho To take no detours from the high road of reason and social responsibility. -- Marcus Aurelius -- 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
A Problem with the web view. [was: Re: [twitter-dev] Please confirm this OAuth flow ...]
Gentlefolk, There is a problem with the web view/three legged OAuth mechanism. The OAuth sign-in mechanism gives no indication to either the browser or an embedded web view that the user has pressed No, Thanks. In both login methods, our app is left hanging in the middle of a login process. This is extremely user unfriendly. It also forces me, to handle this case, to use the embedded web view. When I do so, I can add a cancel button to my sign-in UI. This makes for a less than elegant view of Twitter's sign-in process. (As an iOS developer, elegance is valued by my customers.) By the way, if the user presses the No, Thanks button twice, then Twitter returns a slightly different form submission. Sniffing for this case is fragile. My question: Am I in error? Does Twitter return a different callback value for the No, Thanks case. If not, I humbly request that Twitter add this important, for a better user experience, notification. Anon, Andrew P.S. Allow me to point out that the API login and permissions process at Twitter's competitor, Facebook, always provides a separate success and failure callback. While that may be unimportant to Twitter, it does show a different implementation path could be taken with an API. Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho To take no detours from the high road of reason and social responsibility. -- Marcus Aurelius -- 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] Please confirm this OAuth flow ...
Gentle Twitter Support Folks, There is an ambiguity in the OAuth flow for mobile devices. As I now have little time to move from xAuth to OAuth, I would appreciate it if Twitter Support would confirm the following OAuth flow which uses your routes. 1) Use POST oauth/request_token to get the access token needed for the user web dialog. 2) Upon receiving the request token, open a web view using GET oauth/authorize. This is the ambiguous path for mobile devices. It is specified that this path must be used for desktop devices. As a mobile device is really a wireless desktop device, I believe Twitter wants me to use this route in lieu of GET oauth/authenticate. Other vendors also allow the specification of whether this is a mobile device. They then provide a web authorization dialog appropriate for a narrow screen. It does not appear that Twitter offers this functionality. Could you please confirm this? Finally, as my app runs on an iPad, what is the preferred web view width? (To support both portrait and landscape orientations, it needs to be less than 768 pixels. 600 pixels is a common, Apple suggested, width.) Could you please enlighten me to what is Twitter's preferred authorization web view width? 3) Use GET oauth/authenticate to acquire the access token and access secret. 4) As I haven't yet requested my new consumer key and, hence, do not know some things, will I also be maintaining a consumer secret for my OAuth signature mechanism? Thank you for your support. Anon, Andrew P.S. Thank you for the two week extension for our xAuth to OAuth transition. Because Apple may still reject my app for unrelated to Twitter issues, four weeks is still a totally inadequate period to ensure a zero downtime transition. Please recognize both the risks to our business and the hardship you are imposing on small organizations. Furthermore, Apple's WWDC conference occurs in the middle of your current conversion schedule, this only allows me, in effect, 3 weeks to make this change. You can really hurt us with your imposed schedule. While I doubt that is your intent, it is, nonetheless, a likely outcome. Please double, at least, your conversion period to 8 weeks. Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho When you can't imagine how things are going to change, that doesn't mean that nothing will change. It means that things will change in ways that are unimaginable. Bruce Sterling, January 02, 2009 -- 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
Re: [twitter-dev] A new permission level
On May 18, 2011, at 12:01 , Matt Harris wrote: We know this will take some time so we are allowing a transition period until the end of this month. Gentlefolk, This is way too short an amount of time to implement OAuth and transition mobile users off of an xAuth based client. (In my experience, my user base upgrades an app over a full quarter of a year.) Furthermore, even if I was ready right now with a submission to Apple, there is a very good chance that my app would not be approved by your deadline. Please reconsider this deadline. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009 -- 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
Re: [twitter-dev] Visual refresh of the OAuth screens
On Apr 28, 2011, at 16:02 , Matt Harris wrote: We hope you find the new designs more welcoming and friendly. Let us know what you think. Matt, I'm speaking as a user but I would like for the user to be able to separately deny write access to my account. I don't frankly care if the developer requires it. I think most developers just ask for the moon and get it. Only Twitter can give the user the ability to deny impersonation access on a per application basis. If the app cannot just run with just read access, then the user should really know why. In my experience, most developers just use write access as a mechanism to spread their brand. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho To take no detours from the high road of reason and social responsibility. -- Marcus Aurelius -- 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
Re: [twitter-dev] Visual refresh of the OAuth screens
On Apr 29, 2011, at 15:56 , Jeremy Dunck wrote: On Fri, Apr 29, 2011 at 8:55 AM, Andrew W. Donoho andrew.don...@gmail.com wrote: Matt, I'm speaking as a user but I would like for the user to be able to separately deny write access to my account. I don't frankly care if the developer requires it. I think most developers just ask for the moon and get it. Only Twitter can give the user the ability to deny impersonation access on a per application basis. If the app cannot just run with just read access, then the user should really know why. In my experience, most developers just use write access as a mechanism to spread their brand. There are a few problems here -- 1) Some applications legitimately need write access to do their work - for example, an auto-unfollower. You seem to discount this example. Jeremy, Bear in mind that I wrote my note from the perspective of the user, not the developer. As we've recently seen, developers, at minimum, can get hacked and lose control over all of these credentials. There are other reasons for a user to want to limit that access and Twitter doesn't actually give the user the ability to veto write access. If an app must have write access, they should tell me why. Most apps I've used don't. 2) It is basically not possible to upgrade privileges (with the user's permissions) later, so if an application author thinks they may ever need the privileges, they will ask for write, even if they don't currently need it. What exists now is not carved in stone. Witness that Twitter just changed the login screens and can, obviously, make other changes in the future. You also make my point that app authors ask for privileges they may not currently need. That is not a good policy for users. Twitter's permissions model though encourages developers to ask for more permissions than they need. Twitter should, IMO, change this to protect users. (Yes, Twitter does currently try to protect their users. This is another method they could use.) 3) You seem to feel that the app author is working against you -- if you really feel that's the case, you, the user, are ultimately in control -- you choose whether to allow the application to have access. Actually, the app author is frequently operating at cross purposes to the user. They see the user as a product to monetize. Now you may not view users that way, that doesn't mean every developer behaves as you do. Twitter does ban, as I understand it, many apps every day due to spamming. Twitter can not reasonably be the arbiter of which apps have legitimate write access -- it depends on the utility to you, the user, and so is a personal decision. (There are examples where apps are malicious and misleading, but that is a very small minority of all applications.) You further make my point. I, the user, only get to make the permissions decision when the app is first engaged. Because of this, there is no trial opportunity before I give the app full authority to act on my behalf. I cannot even find out if an app is valuable before giving it full authority to act on my behalf. This is not good for users and is a capability which appears to have been abused by app developers. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009 -- 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
Re: [twitter-dev] Twitter Development platform - A Rant
On Feb 13, 2011, at 08:53 , Umashankar Das wrote: Now, Twitter and it's API groups claim that, they, are putting artificial limits of rates to ensure proper delivery for regular service. Mr. Das, While you make many interesting points in your rant, I think many of them are conjecture and opinion. As reasonable people can disagree about opinions, I've edited them out of my reply. I wish to focus on some unambiguous issues. We each have to make our business bets with respect to the Twitter platform. (I speak as the developer of ch@tter™, an iPad Twitter client. In many ways, Twitter destroyed my business opportunity when they purchased Tweetie and made it free. I mention this for context and not as a cause to rant at Twitter. I'm making plenty of money as a result of building ch@tter™. The iOS consulting business is very healthy.) It is clear from this thread that many developers made, perhaps unwisely, product plans based on Twitter's continued support for white listing. In my case as a client developer, the increase of my API count from 150/hour to 350/hour due to moving to OAuth totally removed my need for white listing. If user streams was supported, I could easily live with 150/hour limit. If they would stand behind their user streams API, I would switch to it immediately. (Beta status is not, frankly, good enough. If they cannot make a commitment to their new API, why should I? By my count, user streams has been in beta for almost 6 months.) Changing a platform's API is hard. Twitter is discovering this the hard way. Every developer has an investment they would like to preserve in the status quo. That said, Twitter's API evolution practices, presumably approved by their CTO, Mr. Sarver, are not, in my opinion, helping their partners grow with Twitter. That they are turning off white listing while not having yet made a production commitment to user streams, is a great example of an evolutionary stumble. That they haven't announced any other methods of enhancing Twitter's ability to scale while supporting functionality enabled by the large white lists is an oversight. The outrage expressed in this thread is good, unambiguous evidence of the stumble. Another example is the closed roll-out of promoted tweets. I think every third party app developer would love to find a way to further monetize their Twitter application. Twitter did announce that they would find a way to allow their developer partners to participate with the promoted tweets program. That has not yet happened. Currently, as Twitter has made a floor price of $0.00 for iOS apps, I have to resort to Apple's iAds to capture revenue from my labors. I don't mind but it does cut my other market-making partner, Twitter, out of the revenue stream. As it reduces my revenue opportunities, I think this is sub-optimal. I win when my partner wins. A third example is the annotation feature. I am sure all of us could find an excellent use for annotations. I have many ideas on how to use them. But I cannot. A fourth example is Chirp? When is it? Will they hold it in a large enough venue? Or is it going to be like their announcement of #NewTwitter. A major announcement whose video was streamed by Robert Scoble? The sound was poor. The image sucked. And, BTW, thank you Robert Scoble. Without him Twitter could not have gotten their message quickly out. In contrast to these missteps, I have to publicly thank Mr. Singletary, Mr. Kalucki and Mr. Harris. Without their constant engagement on this list, the Twitter ecosystem would not be what it is. Overall, everyone needs to remember that we are dealing with a company that publicly claims to not yet be trying to capture revenue from their platform. We are seeing from their experiments the collateral damage. Rolling with the punches is painful. That is the cost of trying to access the almost 200 million Twitter users. What do I want? I want a better developer experience. Both Apple and Microsoft show what a good experience can be. I want user streams, a promoted tweet API and annotations. I hope Twitter can deliver these technical features to enable new business opportunities for themselves and the Twitter app ecosystem. Myself included. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe -- 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
Re: [twitter-dev] Twitter Development platform - A Rant
On Feb 13, 2011, at 13:04 , M. Edward (Ed) Borasky wrote: On Sun, 13 Feb 2011 12:18:11 -0600, Andrew W. Donoho andrew.don...@gmail.com wrote: It is clear from this thread that many developers made, perhaps unwisely, product plans based on Twitter's continued support for white listing. In my case as a client developer, the increase of my API count from 150/hour to 350/hour due to moving to OAuth totally removed my need for white listing. If user streams was supported, I could easily live with 150/hour limit. If they would stand behind their user streams API, I would switch to it immediately. (Beta status is not, frankly, good enough. If they cannot make a commitment to their new API, why should I? By my count, user streams has been in beta for almost 6 months.) User Streams is in fact in production and has been for months. The only restrictions on User Streams, other than what's documented in the technical documentation, is that it is *only* for desktop *clients*, not servers or mobile. I'm not sure where iPad fits in this spectrum, but for sure an iPhone is mobile. *Site* Streams is designed for servers and it is still in beta. Perhaps you need to be pitching your idea to Twitter and adapting your service to Site Streams if it's a server-backed app, which I'm guessing an iPhone/iPad app would be. Mr. Borasky, Any API where the very first line in the schema section says it is subject to change is not, in fact, in production. Now it may be due to sloppy documentation but I doubt it. Twitter's documentation process has become much better. IOW, user streams is in beta. If it is production worthy, then Twitter should commit to it. This API, until they version the route, should no longer be subject to change. That said, Twitter's API evolution practices, presumably approved by their CTO, Mr. Sarver, are not, in my opinion, helping their partners grow with Twitter. [snip] Another example is the closed roll-out of promoted tweets. I think every third party app developer would love to find a way to further monetize their Twitter application. Twitter did announce that they would find a way to allow their developer partners to participate with the promoted tweets program. That has not yet happened. Currently, as Twitter has made a floor price of $0.00 for iOS apps, I have to resort to Apple's iAds to capture revenue from my labors. I don't mind but it does cut my other market-making partner, Twitter, out of the revenue stream. As it reduces my revenue opportunities, I think this is sub-optimal. I win when my partner wins. The key word in this rant is partner. Let me be very clear. The term rant was applied by the opening poster. I am pointing out what I think are concrete issues which we all, as business partners with Twitter should consider. That is not a rant. A *partner* is, IMHO, someone who has a *formal* partnership arrangement. Sure, there's a certain formality when you accept Twitter's TOS, but I think if you want to use Site Streams or Promoted content, you should be negotiating as a business with Twitter as a business. What's in it for Twitter? The ToS is a contract. I've also based my business on Twitter's APIs. I view the APIs and other aspects of the relationship I have with Twitter to effectively be a partnership. Twitter, as the senior partner in this relationship, barely knows I exist. As to what's in it for Twitter? They have support a public API because it makes their product better. And they do want people like me making their and my product better. Twitter has built a powerful brand. I was there in early 2007 when the vast majority of pundits predicted that it would go nowhere - that it was just a bunch of Ruby hackers with too much time on their hands, that it would destroy flow, etc. It's now one of the top ten sites world wide according to Alexa. If you want to be a partner with Twitter, *you* are the one who needs to have something to offer *them* IMHO. And, I believe I do. I suspect that you believe you offer them value and vice versa or you would not waste your time on this list. This email and those of other developers do improve their product. Every bug discovered helps their product. Are we suckers? Perhaps. Overall, I have profited from this arrangement. I wish Twitter well and I hope they improve their relationship with the developer community. [snip] Overall, everyone needs to remember that we are dealing with a company that publicly claims to not yet be trying to capture revenue from their platform. I seem to have missed that claim. As far as I know, they *are* trying to capture revenue through a combination of Promoted Accounts, Tweets and Trends with bundled analytics and data licensing. Stone, reacting to a question from TechEye, said that there was still so much the company wanted to do, including proving that it had
[twitter-dev] Entities?
Folks, Entities are still borked. And have been, by my reckoning, for over 12 hours now. As my iPad product uses entities and is now crashing in the field, I would like Twitter to do one of two things. Obviously, fixing entities is my preferred choice. Failing that though, please turn entities off. (c...@tter falls back to its own parsing code when entities are not present. I am sure other products do the same. Hence, this stops my apps in the field from crashing. (BTW, my alpha builds now catch this error and won't crash in future releases.) I have posted both sample data and notes to both this list and the issues tracker. It is issue 1875 and is at URL: http://code.google.com/p/twitter-api/issues/detail?id=1875q=label%3APriority-Minorcolspec=ID%20Stars%20Type%20Status%20Priority%20Summary%20Opened%20Modified%20Component Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe -- 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?hl=en
[twitter-dev] Errors in entities reported from Twitter.
Gentlefolk,
Twitter is currently sending the wrong JSON data for entities. Two
examples are below.
Anon,
Andrew
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@ddg.com, +1 (512) 750-7596
We did not come to fear the future.
We came here to shape it.
-- President Barack Obama, Sept. 2009
Normal Entity JSON:
{
contributors = null;
coordinates = null;
created_at = Thu Sep 09 22:54:12 + 2010;
entities = {
hashtags = (
);
urls = (
);
user_mentions = (
{
id = 110309681;
indices = (
0,
12
);
name = John Walker;
screen_name = haikuwalker;
},
{
id = 28201579;
indices = (
26,
36
);
name = Launch787 Matt;
screen_name = launch787;
}
);
};
favorited = 0;
geo = null;
id = 24050618494;
in_reply_to_screen_name = haikuwalker;
in_reply_to_status_id = null;
in_reply_to_user_id = 110309681;
place = null;
retweet_count = null;
retweeted = 0;
source = a href=\http://www.ubertwitter.com/bb/download.php\;
rel=\nofollow\\U00dcberTwitter/a;
text = @haikuwalker is headed to @launch787 to bartend their event so
if you're there say hi or flick his ear;
truncated = 0;
user = {
contributors_enabled = 0;
created_at = Tue Apr 03 13:55:30 + 2007;
description = Branding Empath, WOMM believer, Annie Oakley,hoop
girl, @titosvodka creative, tap dance kid, dog saver, paranormal researcher,
prince dj;
favourites_count = 1;
follow_request_sent = 0;
followers_count = 2108;
following = 0;
friends_count = 2269;
geo_enabled = 0;
id = 3321501;
lang = en;
listed_count = 124;
location = Austin, Texas;
name = Elizabeth Bellanti;
notifications = 0;
profile_background_color = ff;
profile_background_image_url =
http://a3.twimg.com/profile_background_images/85553889/back_1_mini.jpg;;
profile_background_tile = 0;
profile_image_url =
http://a3.twimg.com/profile_images/704874191/GetAttachment-20.aspx_normal.jpeg;;
profile_link_color = ff;
profile_sidebar_border_color = 87bc44;
profile_sidebar_fill_color = e0ff92;
profile_text_color = 00;
profile_use_background_image = 1;
protected = 0;
screen_name = BeBellanti;
show_all_inline_media = 0;
statuses_count = 5203;
time_zone = Central Time (US Canada);
url = http://www.bellantibranding.com ;
utc_offset = -21600;
verified = 0;
};
}
In error entity JSON (Please note the broken hashtags and urls entities too.):
{
contributors = null;
coordinates = null;
created_at = Thu Sep 09 22:54:04 + 2010;
entities = {
hashtags = (
RoundRockJelly
);
urls = (
RoundRockJelly
);
user_mentions = (
LaughlinJames,
SheilaS,
MikeChapman
);
};
favorited = 0;
geo = null;
id = 24050609162;
in_reply_to_screen_name = null;
in_reply_to_status_id = null;
in_reply_to_user_id = null;
place = null;
retweet_count = null;
retweeted = 0;
source = a href=\http://www.tweetdeck.com\;
rel=\nofollow\TweetDeck/a;
text = BTW I was looking at my calendar, and I'll be at
#RoundRockJelly around 12:15 tomorrow. cc: @LaughlinJames @SheilaS
@MikeChapman;
truncated = 0;
user = {
contributors_enabled = 0;
created_at = Wed Jul 30 03:18:30 + 2008;
description = I am passionate about a few things: Technology,
Music, Cars, Film, Literature. And when they meet it's a happy land, powerful
man, universe man.
\n;
favourites_count = 2;
follow_request_sent = 0;
followers_count = 594;
following = 1;
friends_count = 1182;
geo_enabled = 1;
id = 15655817;
lang = en;
listed_count = 32
Re: [twitter-dev] Re: Error 401 only in Target (working fine in simulator)
On Sep 1, 2010, at 15:55 , M. Edward (Ed) Borasky wrote: That's a surprise - I'd expect Apple to be on top of stuff like that! Even so, 18 seconds is well within Twitter's outrageously generous tolerance of five minutes. There are different sync. points for different devices. For example, iPhones sync with ATT. iPads sync with Apple. There appears to be a ≈30 second difference between them. While being far from a time sync expert, I suspect leap seconds are the issue. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009 -- 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?hl=en
Re: [twitter-dev] Re: Can we use localhost to tweet messages using oAuth authentication??
On Aug 9, 2010, at 08:37 , Taylor Singletary wrote: As a reminder, it's proper OAuth to always send an oauth_callback on the request token step of OAuth negotiation -- even if you've preregistered a callback or are using the PIN code/out-of-band flow (in which case you would send oauth_callback=oob). Taylor, As a user of xauth, I do not currently send oauth_callback=oob. I think this is because xauth does not participate in the negotiation for a temporary credential. (See: http://tools.ietf.org/html/rfc5849 section 2.1.). Is this your understanding? Or do xauth users need to include this callback in our request for our permanent access token? Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009
Re: [twitter-dev] Image Uploading
On Aug 2, 2010, at 12:19 , Taylor Singletary wrote: Long story short, we're continuing to iterate on this issue and tweak the image manipulation routines we are using. I'd recommend when uploading images that you assure they are as square as possible before upload, but overall, this is something we (Twitter) need to fix so that its behavior is more deterministic. Taylor, I really want the black bars taken out of the images. If Twitter must squarify the image, please use transparent pixels. (I place these images on top of black, white and colored backgrounds.) I need the Twitter user's image layout to come through. (I use, and cache, the high resolution version of these images.) Thank you for your continued excellent support. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009
[twitter-dev] Included Entities and Foursquare...
Gentlefolk,
Included entities do not appear in every tweet in a home timeline
query. The below JSON was returned in a home timeline call with 200 other
tweets all of whom had the entities dictionary. My hypothesis is that this
is correlated with each of the below statuses having geo-location information
in them.
Anon,
Andrew
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@ddg.com, +1 (512) 750-7596
Knowing is not enough; we must apply.
Willing is not enough; we must do.
-- Johann Wolfgang von Goethe
From Foursquare:
{coordinates:{coordinates:[-73.990433,40.744416],type:Point},geo:{coordinates:[40.744416,-73.990433],type:Point},text:Nothing
says 4th of July like a Toga Birthday party for a Penthouse Pet. (@ La Pomme)
http://4sq.com/6E2MPh,truncated:false,favorited:false,in_reply_to_user_id:null,in_reply_to_status_id:null,source:;a
href=\http://foursquare.com\;
rel=\nofollow\foursquare/a,created_at:Sat Jul 03 02:53:02 +
2010,in_reply_to_screen_name:null,contributors:null,place:{full_name:Midtown
South Central, New York,country_code:US,country:The United States of
America,place_type:neighborhood,url:http://api.twitter.com/1/geo/id/cbadf33c47f35f2b.json,name:Midtown
South
Central,attributes:{},bounding_box:{coordinates:[[[-73.992732,40.740219],[-73.977681,40.740219],[-73.977681,40.754888],[-73.992732,40.754888]]],type:Polygon},id:cbadf33c47f35f2b},id:17619465665}
From Echofon:
{coordinates:{coordinates:[-97.770878,30.279587],type:Point},geo:{coordinates:[30.279587,-97.770878],type:Point},text:I
have no doubt that if she knew how to operate the microwave, she would have
done it all herself. She's just like her
daddy.,truncated:false,favorited:false,in_reply_to_user_id:null,in_reply_to_status_id:null,source:a
href=\http://www.echofon.com/\;
rel=\nofollow\Echofon/a,created_at:Sat Jul 03 01:13:43 +
2010,in_reply_to_screen_name:null,contributors:null,place:{full_name:West
Austin, Austin,country_code:US,country:The United States of
America,place_type:neighborhood,url:http://api.twitter.com/1/geo/id/14577ba0f3ece649.json,name:West
Austin,attributes:{},bounding_box:{coordinates:[[[-97.78537296,30.27450699],[-97.75757016,30.27450699],[-97.75757016,30.31476201],[-97.78537296,30.31476201]]],type:Polygon},id:14577ba0f3ece649},id:17613770817}
From Twitter for iPhone:
{coordinates:{coordinates:[-84.34484456,33.73989108],type:Point},geo:{coordinates:[33.73989108,-84.34484456],type:Point},text:Here's
@emarvelous and her new yorkie poo Ginger.
http://twitpic.com/21wc5z,truncated:false,favorited:false,in_reply_to_user_id:null,in_reply_to_status_id:null,source:;a
href=\http://twitter.com/\; rel=\nofollow\Twitter for
iPhone/a,created_at:Sat Jul 03 00:52:50 +
2010,in_reply_to_screen_name:null,contributors:null,place:{full_name:Atlanta,
GA,country_code:US,country:The United States of
America,place_type:city,url:http://api.twitter.com/1/geo/id/8173485c72e78ca5.json,name:Atlanta,attributes:{},bounding_box:{coordinates:[[[-84.54674,33.647808],[-84.289389,33.647808],[-84.289389,33.887618],[-84.54674,33.887618]]],type:Polygon},id:8173485c72e78ca5},id:17612612337}
From Gowalla:
{coordinates:{coordinates:[-97.8320287,30.2963208],type:Point},geo:{coordinates:[30.2963208,-97.8320287],type:Point},text:Getting
the update on @plerts from @Colin â at Lola Savannah Coffee Lounge
http://gowal.la/r/kQbF,truncated:false,favorited:false,in_reply_to_user_id:null,in_reply_to_status_id:null,source:;a
href=\http://gowalla.com/\; rel=\nofollow\Gowalla/a,created_at:Fri
Jul 02 13:31:45 +
2010,in_reply_to_screen_name:null,contributors:null,place:{full_name:Knollwood,
Austin,country_code:US,country:The United States of
America,place_type:neighborhood,url:http://api.twitter.com/1/geo/id/791f17d91e425f81.json,name:Knollwood,attributes:{},bounding_box:{coordinates:[[[-97.83837504,30.29196996],[-97.83011412,30.29196996],[-97.83011412,30.29726997],[-97.83837504,30.29726997]]],type:Polygon},id:791f17d91e425f81},id:17571846061}
Re: [twitter-dev] Re: oauth status update returning error 401 invalid / used nonce
On Jun 30, 2010, at 14:32 , James Ford wrote: One thing I'm perhaps not clear on, do I need xAuth for this to work? You do need to get the access token somehow. That is what xAuth provides you. That said, you sound like you are a server app. Twitter doesn't support xAuth for server apps. You probably need to use the standard OAuth token request protocol. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 To take no detours from the high road of reason and social responsibility. -- Marcus Aurelius
Re: [twitter-dev] Transitioning from Basic Auth to OAuth Guide (need your help!)
On Jun 25, 2010, at 15:42 , Taylor Singletary wrote: However, we'd love to collect together specific implementation stories of developers who've successfully made the transition and highlight them here. Taylor et. al., As someone with his own custom iPhone REST stack, I scaled the OAuth/xAuth wall. In my view, everyone made this transition seem much tougher than it really is. Here's my advice: 0) If you don't have a REST stack, git one! There are many out there. I started with one. (Very little of it remains in my apps but that is another matter. It got me started.) 1) Your http request tends to change in exactly one place -- setting your authorization header. Don't freak out about changing your code base. I added 3 methods to my stack: create a signature string, sign the signature string and create the OAuth header. I changed one method to sort and URL encode my parameters. In all, this is a pretty minimal change. I cribbed much of this from other open source implementations. 1a) Calculating a signature string is not as daunting as it looks. Some pseudo code would have helped. Twitter's recent documentation helped. 1b) Calculating HMAC-SHA1 signature is simple too. If you use the common crypto library (CDSA derived), it takes 6 lines. 1c) What wasn't too clear was how the xAuth process interacted with your tokens. (Yes, I knew they were missing. What wasn't apparent was that I had to leave the conjoining '' in the signature secret.) 2) The WWDC slides sum up most of the issues but leave out the supporting nitty gritty code. Finally, we all know that xAuth has a huge security hole -- the embedded consumer secret in the client app. I have a feature request into Apple to allow the passing of encrypted secrets to native applications through App Store binary code. I have also posted it to OpenRadar at this link: http://openradar.appspot.com/8109678. If members of this community agree that we need a solution to this problem, then please consider filing enhancement requests with Apple via bugreporter and reference my request. (If someone else has a similar request, I'll be happy to reference their request in my communications with Apple.) Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 We did not come to fear the future. We came here to shape it. -- President Barack Obama, Sept. 2009
Re: [twitter-dev] Which IETF standard has the year appearing after the time?
On Jun 21, 2010, at 14:40 , Peter Cross wrote: This date is from a call to http://api.twitter.com/1/statuses/user_timeline.xml: created_atMon Jun 21 19:06:21 + 2010/created_at begin rant Elided /end rant This isn't an XML standard date format either. It is a unicode compatible date. This format string is defined at: http://unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns Here is the format I use to parse Twitter formats into my local time system: EEE MMM dd HH:mm:ss ZZZ y. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe
Re: [twitter-dev] Which OAuth URLs are right?
On Jun 20, 2010, at 06:54 , Jef Poskanzer wrote: Which should I believe? I'm sure all combinations of http/https twitter.com/api.twitter.com work, at least for now, but the dev page seems pretty emphatic that I should use its version. If it's that important, shouldn't the official app page get changed to give the same URLs? I use: https://api.twitter.com/oauth/access_token. As all of the other URLs have moved to https://api.twitter.com/1 as the stem, I would stick with the api.twitter.com URLs. Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 To take no detours from the high road of reason and social responsibility. -- Marcus Aurelius
Re: [twitter-dev] Error: 500 from include_entities
On Jun 18, 2010, at 09:28 , Taylor Singletary wrote: This is a known issue right now -- we've had a bugfix waiting in the wings for this but it hasn't been able to deploy yet. There's a particular kind of tweet condition that when extracted into an entity results in an error. Taylor, Thank for your quick response. I have now posted my report as issue 1700 on your API issues tracker. I understand that Twitter is under a significant load right now and that this may be a low priority fix to roll out to production. As I am about to submit a new dot release of my iPad app, c...@tter, to the iPhone app store, is there any estimate as to when the fix might be rolled out? Anon, Andrew Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596 Knowing is not enough; we must apply. Willing is not enough; we must do. -- Johann Wolfgang von Goethe
