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.
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 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.
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.
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.
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.
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.
What is wrong with these people, just fix twitter so url's don't count to the count.
Morons.
There's no better user experience to a shortened url, it's like having unprotected sex with a random in a nightclub, you've no idea what you could end up with.
Repeat after me, shortened urls break the web and are inherently evil.
There was a comment on Reddit a while back about what the 140 character limit means in different places:
In English, you get a comment.
In Japanese, you get a poem or a brief news article.
In Chinese, you get a short story... it might as well be a novel.
And someone gave an example Chinese tweet that translated to:
"You guys are the Sina fans other there? 'Keep on Perseverance' (some literate group) is publishing some online literature collection, referencing to the sissy poet character in the 'Cellphone' TV series. I know the people in 'Sina Literature Collection" (another group) well since junior high school; often went to their chat room to chit-chat bull. His (Keep on Perservance) main page's arrangement is overwhelming; I can't digest them. My preference is simple, slim, light-breeze style of literature. Hey, today is the clan chief's birthday, too. Don't know how he/she enjoying his/her day in Swissland. May be eating chocolate fondue? I can't do winter hibernation anymore. Have to come out. And have been messing around with you all day long."
There's a tradeoff between larger character set and easier input method. It's not trivial to input Chinese characters with keyboard. It compensates by allowing richer expressions with fewer characters.
Twitter gets millions of tweets and I am sure good percentage of them will have URLs. And if they start checking valid response for each URL, I think soon they will have to build a new data center just for this task. Also, what if the URL is temporarily down? What should they do?
I don't think they need to check for valid URLs. My point is just that disguising text as a URL will be possible regardless unless you check for 404s or ellipsize the URLs. Using a URL shortener isn't necessary to make URLs count for a constant character length.
That's just a tidbit thrown around to soothe those irked by the limit. It's been well over a decade since the last mobile phone was sold that couldn't handle long/concatenated SMS. The reality is that the 140 character limit is just an arbitrary one; one that makes Twitter, Twitter.
Anecdote is not the singular of data, but I have been able to send/receive long messages using Android and iPhone on AT&T.
Just yesterday I even noticed Android's core SMS app is even nice enough to tell you when the message is overflowing into a second SMS, so you know that you and the recipient will get billed for more than one SMS. Which brings me to another idea:
Perhaps the billing issue is more of a concern as well -- receiving concatenated messages certainly would cost more for (American) users not on unlimited SMS plans, and presumably would cost more for Twitter to send out through their gateway?
It's not a defense. It's a fact. My co-worker prefers to receive all tweets via SMS. They advertise the SMS feature at the top of every page. Calling people names at every turn isn't going to make your point more valid.
Besides URL shorteners being totally unnecessary, this just slows down users' browsing and diminishes their privacy. Basically, every Twitter app will have to become Spyware in order to comply with Twitter's new ToS.
FWIW, Here are my messages to the Twitter developer list about it:
I think it is disgusting how Twitter has appropriated the old post-9/11 "we're spying on you for for own safety" stance that governments have been terrorizing citizens with. Basically, their spyware is protecting you from...other spyware. All for a fraction of a fraction of a penny per click.
Also note that their t.co shortener will create links that are 19 characters long. But, j.mp links are only 18 characters long, which means t.co links won't even be as short as possible. So, it's worse all around.
> If you are already partial to a particular shortener when you tweet, you can continue to use it for link shortening and analytics as you normally would, and we'll wrap the shortened links you submit.
I really hope this habit doesn't catch on. If it does each link will have three points of failure instead of one (as it should) or two (as it will with t.co).
Twitter will likely crawl the final targets of the urls, so that when bit.ly goes out of business, the t.co urls pointing to bit.ly can get redirected to the canonical link. So I don't think it's quite as bad as you're thinking.
Apparently if you have a unique word in the expanded version of your url, then search for your tweet containing only the shortened url using the unique word, you will still find the tweet. I've not tested it myself, but I took it as evidence that they are indeed caching fully resolved urls.
"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 surprising.
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 can have link transparency back again.
On a related note, I'm actually quite happy that Twitter is starting to close up their platform. People can stop pretending it's some open platform for global communication and finally realize it's a novel service thanks to its popularity, but little more.
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?
For those that also live in the 21st century, yes. Which mail clients don't render HTML? Perhaps the users who still use ancient mail clients should consider switching, or endure reading HTML. I'm not going optimize for the minority by making web sites in plain text either for the few users who refuse to use a web browser.
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.
While they'll "wrap" other shortening services, what's the point now? People won't use them and they'll fall by the wayside. Not really a bad thing in my opinion (people use them now when they don't even need to) but still a bit of a smack in the face to services that essentially helped Twitter in their early days.
"Twitter clients" is a larger term than you realize. I've done banner campaigns, widgets and promotional websites that all display tweets in ways Twitter would be unable to track without this.
This is ridiculous... why is this TLD being allowed? Its main use is going to be abuse, ranging from squatting to phishing (chase.co, paypal.co, anyone?).
It looks like they're giving trademarks registered before 2008 first dibs, so as long as those big companies' IT departments are on the ball, they can pre-empt the squatters.
Yeah, but for a tax of $300. The big companies will doubtless all register theirs, but there are countless other sites that won't have the time/resources to do this.
Not a chance. However, the traffic value of .co is huge. If you look at .CM as an example... potential for money making is very high. Hotels.co, yes please!
They are running a great campaign, the best one to date in fact. Even so, I feel that .CO is a quality extension in the same field as .TV and .ME which are doing fairly well.
Twitter was given T.CO at no cost as part of the .Co Founders Program. For more info and details on CoInternet the T.CO shortener and the E.CO live auction, I have covered the story here:
can somebody explain to me what the deal is with .co? I see that there is a 3-phase rollout, which seems aimed at maximizing revenue and protecting existing .com.co domains. What is the best site to register/apply for a .co domain name? I have searched to no avail (just found a few sites that seem dodgy)
> "All links included in Direct Message notification emails currently pass through our link service and are converted to a http://t.co link. We've also begun testing this service for links in Tweets"
I'm curious whether they're going to outright put a blanket ban on "alternative" URL shorteners like they did with Twitter-based Ad services.
Looks like they're going to wrap existing shortened URLs with t.co:
If you are already partial to a particular shortener when you tweet, you can continue to use it for link shortening and analytics as you normally would, and we'll wrap the shortened links you submit.
I think URL shorteners are cool, and all the rage, but:
- I remember when del.icio.us/ came out. Not that it's a shortener, but they all have this clever naming crap. When you're not able to click the link, it's awfully hard to remember-- okay, did the first period come after the first three letters? What's the bottom domain, again? How do you even spell delicious? Did they spell it right?
- There's an implicit trust that must be made before expecting a user to click on any shortened URL. Since you can't follow it through to the content without actually clicking on it, there's no way of knowing whether you're headed to a clever browser hijack (or worse)!
- Which brings us to the work-safe barrier that most everyone who works a real job has. Websense, in most cases, blocks anything that's streaming media, TV, porn, advertisements, gambling, etc. etc. etc. And then it logs it, and it logs which user accesses it. When I'm at work, I'm pretty judicious-- I don't want to be recorded as clicking on YouTube links, or listening to Kanye West's latest gaffe, let alone going to Facebook or Myspace. URL shortners completely obfuscate where the link is taking you-- so the damage is done without you even knowing what choice you make. Therefore, unless I'm absolutely certain it came from someone I know, and it's specified what it is, I'm not clicking that shit. Which brings us back to implicit trust.
Most people don't check the links first, or even do this 'trust check' before they click on links. How long until we see, "Woman fired for watching Jack Johnson video on company time?" (accidentally, of course). It shouldn't be that way, but it will be before too long.
Note that the 'dot' (in to.) is necessary to make the hostname absolute, so it doesn't fail in pretty much every browser. Otherwise, the URL should just be: http://to/
Nope. It was registered April 26 2010 by ".CO Founders program".
.CO founders are hand-picked to ensure the domain will "contribute to the .CO community in a meaningful way." In return, they get get first dibs on a .CO domain name, which will be publicly launched in July 2010. (http://www.cointernet.co/domain/become-co-founder)
Maybe it is registered under the program's name instead of the actual registrant to ensure registrants under the program stick with their originally-submitted plan. Or at least they can't turn around and change it to a domain parked ad page.
Or perhaps the whois registrant name will be changed after the public launch.
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.