[apike]

From users' perspective, the big thing here is that clients can now show where links in tweets actually lead. For brevity, the link text should probably just be the domain it leads to, but it should make things a whole lot more readable.

Before - This is a great news site: http://bit.ly/2Mp91y

After - This is a great news site: news.ycombinator.com

A loss for URL shortener services, but a win for users.

[natrius]

Clients could have easily done this before.

  HEAD /2Mp91y HTTP/1.1
  Host: bit.ly

  ...

  Status: HTTP/1.1 301 Moved
  Location: http://news.ycombinator.com/

If the goal was minimizing requests, Twitter could've saved the endpoint on its end and passed the data through the API. A new shortener was unnecessary, though it's easy to see why it is desirable for them.

[apike]

Querying each URL would be impractical to do on the Twitter client side, especially on a mobile device, even simply from the latency before you can render perspective. You could render the tweets with the shortened links and then reflow the text if/when each HEAD request returns, but that would probably result in a crummy, slow experience for the reader as they scroll through tweets.

Twitter could indeed have done it on their side, but just doing it themselves is more efficient for them and provides a bit of extra user benefit - the fact it's automatic so you get more room for text in your tweets, their malicious link protection, and reliability if you assume Twitter is more reliable than J Random URL Shortener.

[natrius]

> Still, skipping the middle man is both more efficient

The middle man will not be skipped. It will be wrapped. Two redirects instead of one.

http://twitter.com/twitterapi/status/15741693182

[apike]

I've updated my post to be clear that I meant more efficient for Twitter, not the end user in that case. Also, my assumption is that people use this instead of normal URL shorteners in most cases.

[natrius]

Ah, I misunderstood.

Regardless, URL shorteners cannot be described as beneficial for users (except those who want to track clicks on their links). They make it take longer to get to the page. They are an extra point of failure. They are bad for users. That doesn't mean it shouldn't be done, but it isn't altruistic by any measure.

[johns]

Nambu for Mac reverses every short URL and does so without affecting the app performance negatively.

[hboon]

That's on the Mac, not on a mobile devices with a higher latency cellular connection.

[sharkbrainguy]

To minimize requests you can run a service that batch deshortens urls. Like the little scheme servlet (70 LOC) I'm using to deshorten urls for my JS twitter client.

the source: http://github.com/sharkbrainguy/deshorten an example: http://bit.ly/amxL0Y

[dacort]

As I interpreted it, Twitter is not going to longify links. The display_url entity will be the exactly link passed in by the user. So if a user pastes in a bit.ly link, it will still show the bit.ly link.