Twitter should make URL shortening moot by allowing a link to be included with each Tweet at a fixed character cost of 5-10 characters.

Everybody hates URL shorteners. They slow down page loads, can frame your content, steal your PageRank and even drop dead without notice (and come back alive in a similarly suprising fashion). I mean, even Jeff Atwood thinks they are hack, and he’s a very practical fellow.

To remedy these issues, some well-intentioned people are putting together a spec for webmasters to declare their own short URLs. The thinking goes, other short URL services would first check the target page and use the webmaster specified short URL if one exists. The difficulty of getting URL shorteners to cooperate aside, there is a more fundamental problem here: we should not need short URLs in the first place.

Let me be more direct: Twitter is the only reason URL shorteners are rearing their collective head again. This, at the end of the day, is simply a design defect. While the 140 character limit is what makes Twitter special, the interaction between this limit and URLs at large has the harmful side-effect of requiring third parties to build applications for the sole-purpose of providing 301 redirects. See above for potential issues with such applications.

As new usage patterns emerge for their platform, Twitter do a great job improving their API to provide the smooth, seamless experience that their users have come to expect. Even better, their developer community does a great job including such improvements in their apps. This, after all, is exactly what is happening with the Re-tweet API right now.

The solution to the URL shortening problem is for Twitter to allow one URL to be included with each Tweet for a negligible character cost (say, 5-10 characters). They could then use their default short URL provider for SMS updates, which do have technical character count limit. More importantly, Twitter could sell the click-through stats of all URLs, shortened or not. Power users of all stripes might be willing to pay for this functionality.

Any experienced developer can tell you that there are a million ways of implementing any piece of functionality. Some are just better than others. They cause less exposure to bugs, implementation issues, or even attack surface. Sure, you could try to implement transport-layer encryption with JavaScript but it’s just not the right place to do it. Similarly, making long URLs play nice with the character limit is a task best handled within Twitter’s API by Twitter themselves.