Update on the t.co URL Wrapper for Aug 31, 2011

[episod]

Hi Developers,

I wanted to provide everyone with a status update on the t.co rollout. Thanks to all of you who have offered your feedback and reported bugs in the past several weeks.

Since the wider usage of t.co links began on August 15th, we've learned a lot from users, developers, and our own performance sensors alike. One key take away is that the length of a t.co link will be variable by necessity. This means that the "short_url_length" values provided to you in the [node:182] method should be interpreted as maximum lengths. For example, if the maximum length was reported as 20 characters, it would still be possible that a link would be wrapped with a 19 character t.co link. We recommend [node:1164,title="using twitter-text to detect URLs"] in tweet input interfaces, and considering submitted links as equal to the maximum t.co URL length, despite the possibility of it being a shorter length.

With that in mind, I'd like to outline our next steps with t.co:

• September 13, 2011 - We'll start returning 20 as the "short_url_length." It may take the entire duration of the day until this returned value is consistent across requests.
• September 14, 2011 - You'll start to see some wrapped URLs actually utilizing the maximum length, in addition to URLs with less characters than the maximum length.
• October 10, 2011 - All URLs, regardless of length, will be wrapped by t.co
• Within next 2 weeks - Entities will automatically be returned in the response to statuses/update and direct_messages/new
• Within next 6 months - Entities will automatically be returned in the response to any method that can include entities

Bookmark [node:1163,title="the t.co URL wrapper hub"] to keep up to date with everything t.co and read up on documentation and best practices. We also continue to work on mitigation strategies for the lack of entity support in the Search API.

While there are bound to be transition pains through these phases, we appreciate your patience and efforts working with us to make t.co URL wrapping an invisible but potent part of the Twitter experience.

Thanks everyone!
@episod

[tapbot_paul]

Thanks for the heads up. I'll once again request that the twitter-text regexes be vended via help/configuration. Also would be nice to have a help/configuration flag for the 10/10/11 change.

[beadleapp]

Great, so before long, due to .co being blocked at work, I won't be able to visit any urls that are posted on Twitter. Thanks for that then.

[znmeb]

A Search client can use your open-sourced tweet text parser to extract entities, right?

http://engineering.twitter.com/2010/02/introducing-open-source-twitter-text.html

If not, maybe the best interim solution is to provide an "entity extraction library" Search clients can use.

[jdrsqrd]

What about www.isitchristmas.com ? How am I supposed to get my lols come december? People will just think i sent them to NO.com (unless it's christmas day then they'll think I sent them to yes.com)

[episod]

Today we produce a display_url that would result in tweets like being displayed like "isitchrismas.com/..." or something like that -- in the future, we might decide to display the full URL or some other treatment. While we recommend that developers use our display_url when displaying tweets, they are free to display the fully expanded_url if they want and feel that it serves their users best. There are trade-offs, as displaying fully elongated URLs can effect page scan time by end-users.

[episod]

Using twitter-text to parse the entities is fairly easy, yes -- but that wouldn't yield you the expanded URLs for a entity embedded in a search result. We're working on making the search API experience with t.co a friendlier place.

[adonoho]

Gentlefolk,

As you are now requiring that folks check "GET help/configuration", I request that Twitter remove the rate limits on this endpoint.

Anon,
Andrew

[artesea]

I've noticed that on both twitter.com and search the title attribute of links are set to the final url even for bit.ly links.
I thought that new twitter was built on the api allowing us to have the same data (and bugs)?

[episod]

Hi everyone,

A friendly reminder that we'll be beginning the process of increasing the maximum t.co URL length to 20 characters tomorrow, September 13th.

Once this change begins, you'll notice that the value returned in GET help/configuration will begin indicating the 20 character length instead of 19.

While not all URLs wrapped with t.co will be the maximum length, you should begin seeing both 19 and 20 character long t.co URLs later this week.

Thanks everyone.

[ShanghaiTimes]

I have found I think an interesting situation relating to t.co strings.
I am using AS3 and tweetr library, and sending this string:
"woohoo... http://maps.google.com/maps?q=37.714008,+-122.41675+(This+is+where+I+am+now)&iwloc=A&hl=en&ll=37.714008,-122.41675"

It's wrapped to t.co as a tiny url;
@Robert Chalmers wrote: woohoo... http://t.co/cKSzZRm

but when it appears on the Twitter timeline - it's back to being the full length string.
and of course is useless because most of it is missing.

so I am not sure, but it appears that t.co will unwrap an already shortened string?
Does anyone know what is going on here?

thanks
Robert

[episod]

When it displays the wrapped URL on twitter.com, it uses a value called the "display_url" from the Tweet's entities. This display_url isn't really a URL at all but just a friendly string summarizing the link, like "maps.google.com/..." -- the actual destination of the URL is t.co, which will then redirect to the full maps.google.com URL that you originally wrapped.

[Wuup]

Thanks for the info.

[steemcb]

One of the problems with the t.co shortener is that on Android, the way t.co redirects means that the Android OS never broadcasts the fact that it is loading the URL the shortened link resolves to. The Reddit Android app is able to intercept these links when broadcast by Android but with t.co shortener it never gets the call. My own app (The Journal) uses a the same functionality to open stories in the app rather than the browser. If there is anyway this could be fixed it would be much appreciated.

[ShanghaiTimes]

ah, I see. Thanks. This explains why it works on the PC browser, but when displayed on my iPhone, the link is actually shortened. It can't be followed.
Or put another way, that "friendly string" is actually seen as the real string.

[episod]

Can you explain a bit more about this issue? Is there a different User-Agent that gets used in this context as opposed to the standard User-Agent utilized by the Android browser? Does the in-app browser still display a URL/location bar? If not, is it possible to force it to?

[steemcb]

Hi Taylor, thanks for replying. The browser used is the standard default Android browser and displays the the URL fine - the problem is that when the t.co link is resolved to the full link, the Android OS never broadcasts the fact that the browser is loading that resolved URL. I believe it is due to the way that t.co redirects to the resolved page that causes this.

You can test this by installing the reddit app and clicking on a reddit link in a webpage. The reddit app will offer to open that link via it's app rather than the web browser. Now try going to the same link via a t.co shortened link - the app will never offer to open because of the way the t.co link loads.

[talklittle]

Let me try to clarify--Android uses a system of Intents, where every time you click a link, e.g. from the Twitter app, it will fire an Intent out to the whole system containing the URL of the link. Every app you have installed has the opportunity to specify an Intent filter, which may include a clause saying "I want to intercept all URL Intents fired for domain zombo.com".

However, if zombo.com is now hidden behind the shortened URL t.co, none of these Intent filters will work, and the link will always be loaded by the default Browser app. I can imagine workarounds for this in the Twitter app itself, where the Intents it fires might, in the future, not be the t.co link but the full expanded link--of course Twitter would then track Android clicks a different way, like in the Android app rather than through t.co. It's something the Twitter devs will need to think about, since the new t.co links do circumvent a major feature of Android.

[episod]

Shouldn't the Android OS broadcast the URL regardless of how it was arrived at? This sounds like a bug in how that browser is working in conjunction with OS-level hooks and features. There is great variance on the web between Javascript-based redirects and 302 HTTP-based redirects. We try to do the right thing based on user agent, but the variance exists regardless of whether we're doing it one way or the other. I would bring this behavior up as a bug to the Android team perhaps.

Meanwhile, I'll see if I can get some research into the Android browser's User-agent strings -- and whether they're any different for an embedded browser and see if we can adjust the approach by context here.

[goresponsa]

Hi, i've read in the comments and in the FAQs that i'd be able to set the shortening option t.co from the settings of my app, but i've looked at all the options of my application and i can't see anywhere where to enable it...any suggestion?