Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter launches own shortener t.co

blog.twitter.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Twitter launches own shortener t.co

#71

Post by aditya »

tdavis wrote: post #59
marbletiles wrote: post #54

"routing links through this service will eventually contribute to the metrics behind our Promoted Tweets platform and provide an important quality signal for our Resonance algorithm" So this is Twitter's Digg bar: they want to wrap and trace every link that goes in a Tweet? So much for all those custom bit.ly domains. So much for bit.ly. These guys are going crass quick. @alex's decision to quit is less and less surp…

So much for bit.ly. And this is great news, as far as I'm concerned. Generic shortened URLs are becoming a plague upon the web and are marginally useful at best outside of Twitter. Even more props to Twitter for demystifying links where applicable instead of taking the easier route of pure obscurity. The sooner third-party shorteners disappear from Twitter the sooner they can disappear from the rest of the web and we…

Generic shortened URLs are becoming a plague upon the web and are marginally useful at best outside of Twitter

Marginally useful at best outside of Twitter? Care to explain? Less than 1% of bitly's traffic is coming from twtitter, so obviously there are other people that find value in trackable URLs... I'm curious why you think it isn't useful?

Re: Twitter launches own shortener t.co

#72

Post by cmelbye »

makmanalp wrote: post #65
cmelbye wrote: post #38

Earlier quoted context omitted.

That would be incredibly unhelpful. It's much more to type, it's yet another thing to sanitize, and most users don't know HTML.

You just do: visible_text|url , or maybe that whole thing in brackets. It turns it into an anchor. There, was that so hard?

Or you could just type in the URL. Oh wait, that's exactly what Twitter is doing.

Re: Twitter launches own shortener t.co

#74

Post by india »

aditya wrote: post #71
tdavis wrote: post #59

Earlier quoted context omitted.

So much for bit.ly. And this is great news, as far as I'm concerned. Generic shortened URLs are becoming a plague upon the web and are marginally useful at best outside of Twitter. Even more props to Twitter for demystifying links where applicable instead of taking the easier route of pure obscurity. The sooner third-party shorteners disappear from Twitter the sooner they can disappear from the rest of the web and we…

Generic shortened URLs are becoming a plague upon the web and are marginally useful at best outside of Twitter Marginally useful at best outside of Twitter? Care to explain? Less than 1% of bitly's traffic is coming from twtitter, so obviously there are other people that find value in trackable URLs... I'm curious why you think it isn't useful?

URL shortners break the web in many ways.

Link rot, link hijack, it takes longer to reach the page, additional point of failure and domain based algorithms break. In other words, plague.

Re: Twitter launches own shortener t.co

#76

Post by johns »

apike wrote: post #27
natrius wrote: post #17

Earlier quoted context omitted.

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.

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…

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

Re: Twitter launches own shortener t.co

#77

Post by hboon »

mitchellhislop wrote: post #64
marbletiles wrote: post #54

"routing links through this service will eventually contribute to the metrics behind our Promoted Tweets platform and provide an important quality signal for our Resonance algorithm" So this is Twitter's Digg bar: they want to wrap and trace every link that goes in a Tweet? So much for all those custom bit.ly domains. So much for bit.ly. These guys are going crass quick. @alex's decision to quit is less and less surp…

Also, reading through the dev documentation for this, "No user will ever see a t.co URL". All they are doing is wrapping the URL, not actually changing anything. All services that have their own URL's will be 100% fine.

That's not true. Their API will now return the t.co URLs in the text section, so if developers don't do anything extra, things will (should, rather, I'm clarifying with them) still work, but t.co URLs will be displayed to users.

Their API will return the original links too with markers, so client code can be updated to display the original URLs. Twitter wants developers to display the original URLs and link to the t.co URLs.

Their rational behind this is flawed. One of the reason they are giving for implementing this is to be able to shut down links if they turn out to be malicious, possibly as a bait and switch. But since the right way to do a shortener is to do a 301 and that's what they say they are doing, they wouldn't have that ability.

Re: Twitter launches own shortener t.co

#78

Post by hboon »

johns wrote: post #76
apike wrote: post #27

Earlier quoted context omitted.

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…

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

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

Re: Twitter launches own shortener t.co

#80

Post by coderdude »

briansmith wrote: post #67
coderdude wrote: post #12

Earlier quoted context omitted.

It's been said one hundred million times, but the reason is for SMS.

It is an excuse. At most, they need to shorten the links only for SMS; they don't need to shorten them for the API or for the website (as they've just demonstrated).

I can click on links that come in via SMS on my Droid. Why kill that emerging functionality?

Edit: I completely read what you said incorrectly. My response must make no sense.

Post reply on HN