Slashdot Mirror
URL Shorteners Get Some Backup
URL shorteners are problematical, as everybody knows, but with the rise of Twitter and its ilk they seem to be a necessary part of the landscape. Some of the biggest questions around services such as bit.ly, TinyURL, and is.gd is what happens when they go out of business (as tr.im did last August). Now a group of such companies, organized under the auspices of the Internet Archive, has formed a non-profit entity to hold URL-shortening databases in escrow, with the intent of continuing to resolve a member company's links should it get out of the business. At announcement, the 301Works organization has 21 URL-shortener members, including the largest, bit.ly. Many others are not (yet) on board. The members have agreed to cede control of their domain names to 301Works.org should they exit the field, and to back up their URL mappings regularly to the organization.
URL shorteners are problematical, as everybody knows, but with the rise of Twitter and its ilk they seem to be a necessary part of the landscape.
Seriously?? I know editors frequently get grief for this sort of thing, but come on... the word is problematicalic, for crying out loud. ;)
I have a great proof why this won't work, but it's too long to fit in into a URL :(
Sorry, I mean srs bsns.
You'll never get rid of "link rot", only mitigate it. Even archiving services have a non-zero chance of going under.
Hopefully bit.ly's commitment will force the other common players (tinyurl, tr.im, etc) to join as well. Bit.ly was the only main player on their list so far. A great next-step would be to get the twitter image sites (twitpic, img.ly, etc) on board as well.
URL shortners only server for twitter posts and other place where you need to count characters, these links become pointless within days of a post (some think they become useless even earlier than that), so why bother preserving them after that? let alone when a provider goes bankrupt.
p.s I'm only posting this so i can get some karma to go troll apple ;)
IranAir Flight 655 never forget!
If one of these companies goes bankrupt, their creditors will demand the only valuable asset: the domain name. Does their agreement with 301Works overrule the creditors claims?
qkd2f
My first program:
Hell Segmentation fault
running these things?
$6.99 a year for the domain with free standard hosting from GoDaddy and you're set.
It's not like it's a particularly difficult task to create and run these types of sites. With a simple cron script to clear out links which haven't been clicked in X amount of days you won't even have to worry about your DB ballooning out of control.
Throw up Google AdSense on the user facing side to draw in funds and point both GoDaddy and Google at the same bank account. Google giveth and GoDaddy taketh away. Throw in a hundred to start and you're good to go for a decade.
Work Safe Porn
A governing body should not have to step up to preserve these databases.
Wtf? There is an unbelievably simple way to deal with this. Make the URL shorter, not the link it points to.
"http://tech.slashdot.org/story/09/11/14/184256/URL-Shorteners-Get-Some-Backup?art_pos=1" could become
"tech.slashdot.org/story/..."
in the text, but with keeping the long link it points to, so you can still see it when you hover the mouse over it. This is what StackOverflow does in the comments, and it works perfectly.
If bit.ly is the largest, I wonder why I haven't heard of it. Granted, once you find one, then it's golden. But I've never seen a bit.ly shortener. I've sone loads of tinyurl.com hashes, but never any bit.ly.
URL shorteners are a scourge. As someone else pointed out, they're only really useful for Twitter, with its artificial post-length constraint. Anyone who links to a tinyurl on an actual Web site (such as Slashdot) should automatically be assumed to be a troll, because the only reason to use an URL shortener is to conceal what you're actually linking to.
Breakfast served all day!
You've apparently missed the point completely. Twitter and similar sites have a character limit on messages. That includes all HTML markup.
Plus, there are times when you can't copy/paste a link, and would prefer a shorter one to have to type.
Is this a troll? The USA did not invent SMS.
Functional programming... for real men!
Seriously? You've NEVER looked at someone's post from 2--5 years ago, saw a link about something happening at the time, and wanted to follow it to see more? History should still be preserved for others, even if you think it's only of passing interest to you. In fact, most things are more interesting much later as culture changes and new facts are revealed than they are at the time, when the details of most things could be guessed at from the immediate context that everyone is immersed in just then.
These private URL shortening sites shouldn't exist anyway. They're just a hack to support long urls on mediums that can't handle proper html-style linked text (aka hypertext). Those mediums are buggy should be upgraded (if only by footnote style guidelines).
The bigger issue is private databases, and that all these sites are independent, with separate domains and slightly different urls. The proper solution to that is probably to replace shortlinks with URNs, some DNS/directory/mirror protocol extension that allows browsers to find the nearest server that handles SHORTNAME://MYURN style links, and to essentially query it for "whatever webserver(s) can provide the file referred to by MYURN".
Now, I may be missing something here...
But can someone enlighten me why it would be "problematic" if such a service would go out of business?
All they do is redirect to the original url. So where is the loss?
The original url is still there. If no one is able to find it without using the shortened url chances are pretty big it isn't much interresting anyway.
Life starts at the end of your comfort zone.
Does anyone else find it odd that the White House's twitter page uses bit.ly urls when .ly is the top-level domain code for Libya?
But then what happens when 301Works dies?
That stupid characters limit is self-imposed, they're the ones who created the problem. The easiest solution is to not count HTML characters, meaning you could have a 200 characters URL but be limited in length for the anchor text itself.
It also does unnecessary traffic and adds a delay. Doesn't seem like much, but let's say in five years everybody does that:
1. You click a link
2. Your browser does a DNS request for the shortener domain
3. The shortener website takes the short URL, fetches it in its database
4. Your browser receives a redirect to a new domain
5. Your browser does a DNS request for the actual domain
6. The actual website is sent to your browser
Steps 1-4 are added only for the benefit of an artificial, self-imposed limit from ONE website?
Fuck Twitter.
From what I see they are just for transient things such as Twitter or blog posts - why would someone permanently link using one of these services?
These private URL shortening sites shouldn't exist anyway. They're just a hack to support long urls on mediums that can't handle proper html-style linked text (aka hypertext). Those mediums are buggy should be upgraded (if only by footnote style guidelines).
Have fun upgrading SMS in the network back end, all the handsets that support it, and how it's billed across all carriers globally.
Not that the web should downgraded to support inferior systems, but mobile does have full web support these days, and there is such a thing as MMS these days.
Some websites have user-friendly URLs, such as "www.apple.com/macmini/". You don't even need to click that link to know what it's about.
Other websites have dumb, half-friendly URLs, where they add the backend technology inside the URL, such as "http://www.logitech.com/index.cfm/mice_pointers/" (what's with the "index.cfm" in the URL?). If they fix that problem, all the links pointing to the current URL will break. If they ever change technology, it's also going to break the links from other websites.
And then we have the URLs designed by web monkeys, such as the link for Dell's new Adamo laptop: "www.dell.com/content/topics/topic.aspx/global/products/adamo/topics/en/us/adamo-onyx?c=us&cs=19&l=en&s=dhs". What the HELL is that thing? Even if we forget the parameters at the end, look at the path of that thing! I don't care how your crap is organized on the server, the URL should be much simpler than that!
And last, we have completely brain-dead URLs that seem to be created for computers only, without any chance of figuring out what kind of content is waiting for us on the other side of that link. Crap like "http://www.sonystyle.com/webapp/wcs/stores/servlet/CategoryDisplay?catalogId=10551&storeId=10151&langId=-1&categoryId=16154&SR=nav:electronics:computers:notebook_computers:shop_compare:ss". We're lucky to see "notebook_computers" in the parameters, sometimes it's just a database reference number.
But even with crap URLs like that, unless you have to spell it, write it down or read it on a (paper) page, such links can be hidden behind simple anchor text such as Sony Laptops.
Twitter is its own problem, they should be the ones to fix their own mess. Someone could start a service similar to Twitter but without counting HTML code as being part of the X characters limit, which seems to be what the fuss is all about.
Participating companies will provide regular backups of their URL mappings to the 301Works.org service. In the event of the closure of a participating organization, technical control of the shortening service domain will be transferred to 301Works.org in order to continue redirecting existing shortened URLs to their intended destinations.
Proper handling of the final destination of these links is the responsibility of webmasters operating the targeted sites. Competent operators use HTTP redirection to correctly handle outdated inbound links. Failure to do so in the case of shortened URLs causes no additional problems beyond those caused by people attempting to use the original links.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Maybe we could just issue unique IDs for everything on the Internet. I'm not sure how many would be enough. It could be 64-bits, or perhaps even 128, although you can be sure that if we did that some comittee would probably come up with a reason to gobble up bits. Then of course you'd need some bits for private URLs.
I'm not sure what you call it, but plainly some protocol is needed for all these URLs on the Internet. A kind of... "Internet Protocol", or IP for short. Yeah, that's it. Is anybody working on that?
(end sarcasm)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Character limits and no copy/paste... I thought this was the 21st century?
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
Make the URLs/URIs/IRIs short in the first place, and get rid of the problem. (.html, leading double slash, trailing slash, www...) /saves/ network traffic in the end.
And use title of page instead of plain IRI.
No need query servers with cryptic fake-URIs to get the real ones. Sending the full URIs actually
why don't twitter and others scan tweets and replace third party shorteners with their own shortener services? it's really not that hard to do!
One reason the link-rot threat is very real is the little guy.
I run a url-shortner (ish) service because it's fun and I can.
While, I would love to defend url shortners, my advice to a friend would be : don't use these for anything important. They are not to be used in place of bookmarks. If you have a site or a blog.. just use the real URL in the href. You can beautify it any way you would like inside the "Anchor" tag itself. We've been doing that for two decades now.
Also, the link-rot threat is quite real. SoCuteUrl is simply a fun way to send an otherwise cumbersome link. It's more memorable.. easy to write down, text, etc.
I run the site because it costs very very little to do so and is a very easy to thing to have set up. And, it's fairly easy to maintain.
This is where the problem lies. These are so easy to engineer that virtually anyone can do it. Yes, even slackers like myself with a tendency to flake out on personal projects.
301Works Looks like a decent solution. I will be evaluating it for my own site (socuteurl.com).
However, the membership fee, which does not exist now could prove problematic. My site makes no money. $1,000 a year may not be a lot of money for a site that makes some kind of profit, but it's a lot to support a hobby.
I think 301works may have to come up with a better way to support their costs. Since the biggest threat to link rot.. are the sites that don't make money! I think the membership fee if instated should be optional, and donations should be accepted. Or, perhaps the membership fee can be scaled down for sites with small dbs to upload.
You read my mind. Even if this "301Works.org" succeeds, they could go bankrupt as well, and then you still have the same problem.
Furthermore, what does it matter if http://tinyurl.com/e10zz stops working ten years from now? Nobody cares. Odds are good the link wouldn't work even if the TinyURL was preserved, due to the natural tendency of websites to rearrance their directories. (Note: Remove the last z if you want to see naked women.)
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Those of us who still participate in discussion forums via Email or Usenet have a ~70 character character limit on URLs. If it exceeds that amount it will break across multiple lines and no longer function. Although readers could just copy-n-paste all the piece together, the TinyURL provides a way to convenient way to avoid that.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
How about the website owners make the URLs shorter. It would be really fun if I wanted to, say, send that link to someone in SMS or post on a website from my cellphone .......
83322244177775552777744366681666777411111111111111177778666777999
(if you can't tell, my example is "tech.slashdot.org/story"
Instead of going to tinyurl or a similar site and getting a shorter url. A similar problem is when you need to print the url (for example in a magazine). Printing it isn;t difficult, but when someone wants to go to that site, they need to enter it. Bonus points if the url is case sensitive.
But, I just don't understand how that cutens ANYTHING!
Slashdot covered the benefits of using url-shorteners to reduce bandwidth waste only last March! Everyone is so eager to prove how sophisticated they are and toss hate on an admittedly stupid fad (twitter) that they're prepared to pretend there are absolutely no benefits to using the types of services talked about in the article. I thought this was supposed to be a geek site, not some silly MMORPG where the only thing that counts is how high your comments get rated?
Remember this?
There's a reason why people use url-shorteners, and that reason is because they have a benefit to their use! Many of the more savvy tech sites have begun using them internally to save that 'as much as 75MBit/sec of bandwidth' mentioned in the Slashdot headline. If there is a group getting together to ensure this usage can continue to live on even after the death of the individual services, so much the better! This should be seen as good news...
Instead you half-wits decided to forsake any semblance of geek cred you may have had to whine about Twitter... stuff like this and I wonder why I even come here any more!
--bornagainpenguin
Have a Virgin Mobile USA smartphone? Give VMRoms.com a try!
It's not any different than the link rot you get from expired domains. The number of dead links on the internet are massive. I find myself popping onto webpages that haven't been updated in several years. and all the Geocities links are dead. Internet Archive tries to mirror what it can, but it's more of a band-aid over the real problem.
“Common sense is not so common.” — Voltaire
You don't want one from California dude, they're all in the union. Cheaper to hire one from Alabama and fly him to Cali than it is to pay those union wages! As a bonus the one from Alabama usually will have a better gun and you can probably get a discount if you tell him the target is a Yankee.
ACs don't waste your time replying, your posts are never seen by me.
They also give you a way to send people to places they would normally have the good sense not to.
Cool!
What? There's no need to change any of the "means" of transmission. When a person reads an sms and a) copies the link to his/her PC browser or b) tells the phone to follow that link, does it matter that the TEXT in the link is "http://bit.ly/asdfasdf" or "short://0923abf84"? Nope, it doesn't. Any device connected to the internet can use any of the theoretical URN to URL mappers (there are tons and tons of research papers written on this and how DNS is crippling the web, etc.) I'm just way too tired to explain any further, but, please, next time you try to make a point, make sure you do have one.
Are you serious? HTTP is a text based protocol. If you really want to optimize that much forget about shortening your urls and turn on compression.
So do it internally. There's no reason slashdot couldn't turn all the URL's on their own page into
http://slashdot/a
a-z 0-9, then add 2 digits, then 3, then 4. That should last you a while.
I'm not a nig fan of url shortening services, but sometimes it makes sense.
Sometimes I just want to send a link to my friends with my dumb phone. The problem is that I don't want to type the whole stupid url and I don't want my friends to ask me if it's an Oh or a Zero. In that case, SocuteURL rocks!
Why don't they use zip compression on the URL text? Just post the compressed string instead.
Actually, those who use email or usenet with non-broken software have no such limit, because such software either detects URLs and doesn't wrap them, or lets you easily switch to manual line wrapping as needed.
(Note: Remove the last z if you want to see naked women.)
This is why I love slashdot. And why I kind of want to start messing with link-finding regexes to leave the last character out of the href.
How are sites slashdotted when nobody reads TFAs?
Some of the biggest questions around services shch as bit.ly, TinyURL, and is.gd is what happens when they go out of business (as tr.im did [CC] last August).
Yeah, it's out of business, but now it's open-source and not-for-profit (IIRC). I use tr.im a lot and it works just as good, if not better, than any other URL shortener I've used even.
"Our country is not nearly so overrun with the bigoted as it is overrun with the broadminded." -Archbishop Fulton Sheen
Still, there's no reason that Slashdot couldn't have slashdot.org/184265 link to the same page. Thinkgeek does this - when you browse around, you get thinkgeek.com/category/subcategory/id, but linking to thinkgeek.com/id works perfectly. Slashdot, not so much (that links to the home page for whatever reason).
It's still not as short as j.mp/f00b4r, but it eliminates an additional point of failure. Of course, most of the links that people are sending over twitter et al that bit.ly is shortening are so transient in nature that it barely matters if the service dies.
What they should have is some sort of standard for built-in shortened links, that link shortening services such as bit.ly would provide by default. <link rel="short" href="http://slashdot.org/184265" /> in the head tag would suffice. There's already something similar for canonical links/permalinks, but that's mostly for SEO.
How are sites slashdotted when nobody reads TFAs?
These private URL shortening sites shouldn't exist anyway. They're just a hack to support long urls on mediums that can't handle proper html-style linked text (aka hypertext). Those mediums are buggy should be upgraded (if only by footnote style guidelines).
Could you clarify this? How does what you're suggesting help me read a long URL over the phone? Or type one from memory? Or paste one into an IM or IRC chat window?
So the linkage doesn't have to be preserved/implemented, only documented. They should publish their mapping database sometimes.
It's not difficult to write your own. I did it (not going to link to it because my server probably won't handle the /. effect.)
They can't even decide on the name. In their Terms of Participation, they refer to
themselves as 310works, not 301works. Later they refer to themselves as 201works.
This does not appear to me to be a very professional company if they can't even proofread their own page...
And this part gets me:
Participating companies will be encouraged to place a ‘301Works’ badge on their websites, indicating that they are operating in accordance with these terms of participation. We will generate these badges so they will include the 301works logo and the company’s logo.
They get free advertising on all of these sites. And last section says they *MAY* impose a fee later, like a $1000/year....
I'm providing my services for free, no guarantees, warranties or promises. If I go belly up, well, to bad... But with their proofreading "skilz" and free advertising, and possibly charging a fee later on, I think I'll pass.
The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!
Hi, grammar (and spelling!) fails in sig, but judging from post content, it doesn't matter.
I feel fantastic, and I'm still alive.
./ seems biased against long URLs. When I try to paste one from http://iliil.com/ or http://011010.com/ I get: "Filter error: That's an awful long string of letters there."
Years ago I ran a web server off a home connection using Windows Me and Apache.
I logged over 1 million page views in a month.
As someone else mentioned, it's (possibly) all the click tracking and storing of links perpetually which will eat up database space which results is lower response time without more or better hardware.
Work Safe Porn
I think the article you cite criticize the use of ridiculously long url such as http://www.google.com/search?q=slashdot&ie=utf-8&oe=utf-8&aq=t&rls=org.debian:en-US:unofficial&client=iceweasel-a which is not even that bad. If you want short URL to save bandwidth you can change the URL for the one you manage and run a short url service yourself for the one you do not manage.
The main feature (redirecting) is trivial and capable of being handled with a GoDaddy account. The economy package (free with domain) gives you 300GB per month of transfer and 10GB of space to work with. GoDaddy claims to limit the size of your DB to hundreds of megs or so but the real limit is several GB.
I can see that the additional features of tracking clicks and what not (which should be handled on the individual sites, not by the url redirector) would result in far more resources being needed.
If these sites don't want to go out of business due to increasing costs then the issue is trying to offer more than they need to. Cut features and stick to the core functionality.
But, I guess some people would rather drive themselves into the ground than look for ways to save money and resources.
Work Safe Porn
Bit.ly is currently the number one URL shortener because Twitter automatically uses them when a non-shortened URL is sent.
Work Safe Porn
I'd like to see that shortener database stored as a distributed hash table, and clients can either query it directly by joining the DHT or, as you said, use a service that exposes an simple API that queries DHT.
Heck if they go bankrupt why not just release their database as a torrent and let other people get it if they want? Not like it'll do them any good to keep it private anyway.
The source code is available on e44.us/1.
You can "log in" with your gmail account so one day you can edit your short links.
Anyhow, it's a simple app for now but if there is interest in a "community" OSS project, we can add cool features like, make personalized forms of the app (urls like e44.us/fred/1) or even your own domain (which you can do now with a Google Apps account), optimize it for mobile phones, validate access to URL's etc etc. If you're interested, let me know.
http://2sa.me/ is my own URL shortener service I just whipped up.
It's running off a GoDaddy account.
It's using a two hash method of storing and retrieving URLs quickly. The URL is stored once based on the MD5 hash of the URL (for finding URLs that are being submitted) and once based on the MD5 of the short code (for fast lookup when redirecting). Given one you can find the other. URLs are stored across 4096 tables.
We'll see if it manages to earn $9 over the next year.
Work Safe Porn
How's about Twitter just stops imposing a stupid arbitrary limit on post size, and then we wouldn't need these horrible services?
The SMS message length is a red herring - when was the last time you saw a phone that couldn't handle multiple messages strung together? And I know it has the side benefit of encouraging brevity and stopping people using it like a full-blown blog, but honestly, there's no need - Facebook status messages don't have a length limit (that I've hit, anyway) and I don't see anybody knocking out War And Peace in there, because it's just not the medium for that sort of thing.
You've apparently missed the point completely. Twitter and similar sites have a character limit on messages.
Which is the problematic part. Totally unnecessary today, only still used to create some hype.
Those of us who still participate in discussion forums via Email or Usenet have ...
upgraded their email and usenet readers and do not experience those limits.
Or being wiped out at the decree of an acquiring company's corporate overlords.
Yahoo and Geocities anyone?
I think the OP is referring to a compression algorithm, instead of a cryptographic hash. It sounds like a good idea.
Perhaps this RFC can recommend the use of reserved domain names for compatibility purposes (i.e., http://x.invalid/foobar)
Indeed, that's what I wonder, too. It doesn't matter whether it's zip or anything else (indeed, zip is probably not the best choice in this case), as long as it's a reversible algorithm. Heck, you could even build encoding and decoding it into the web browser directly, and thus remove the need of relying on third-party web sites to get to your actual destination.
The Tao of math: The numbers you can count are not the real numbers.
Because releasing the link database doesn't keep the links working?
You need to maintain the link database AND make sure that the TLD stays with someone that maintains the redirection service. In this case, they're exchanging the link database for that maintenance.
There might also be data mining issues if you just release the database.
Cool, now you can get your OH JOHN RINGO NO goodness at http://www.socuteurl.com/cheekyfuzzydoo
My heart is about to explode from the cuteness.
Because 10 years isn't that long to hold a given piece of data. You don't expect a book in a library to disappear 10 years from now - it will still be at the same "address" in the catalog as it is today, although its physical shelf location may have changed based on the addition or subtraction of books from the surrounding shelves. For very old books, the address may be slightly updated when the book is replaced, but it will still exist - and it will exist in multiple libraries, at the same time. Just because we're used to the fluidity of the internet doesn't mean we need to give up on data permanence or redundancy. I agree it's difficult to keep every bookmark or shortened url accurate based on the fact that people do change their directories occasionally, but there are easy ways to redirect a missing subdirectory back to the home page where a visitor should be able to navigate back to the intended page.
I'm all for archiving parts of the internet. People create and display amazing things here, some of which are never going to be put on a hard copy for distribution and some of which I will still want to visit in 10 years. I hope this site actually works... regardless of the tripe that's being saved.
It brings up the question of why such excremental links need to exist in the first place. WTF do we need guids[1] in our links?
[1] Especially the Microsoft spawned ones?
"You'll never get rid of "link rot", only mitigate it. "
It would be nice if we had some kind of weblike distributed permanent publishing system which was write-once and monotonic. Like Freenet, but without the obsessive secrecy (and child porn), and based on smaller chunks than 'pages'.
Ie, every chunk of data is given a hash and put out onto the ... permaweb. Now it's out there, it won't change. Ever. But it can be cached aggressively (think huge caching servers on every continent, big ones on every network, one per host). These chunks could represent anything: files, emails, web forum comments, Twitter updates, blog posts/edits, Wiki edits, user identities, single value assignments for a single field - anything.
Then to close the gap and make it a full-fledged Web-2.0y system, we'd need other chunks which can be interpreted as functions which aggregate chunks and create 'views' of them, and some way of defining relative rather than absolute names for chunks (such as 'now' and 'here' and 'this process/user/host/network'). And a way of a function-chunk subscribing to those 'relative' chunks so that it gets notified (and recalculates and notifies its subscribers) when they change. That part is a little tricky since it means defining a language.
But even just with massive caching of permanent data, I think we could remove a lot of the suckiness from the current interwebs. We sort of broke the Web way back when we allowed cgi scripts and Javascript; now a web page isn't the primary unit, nor is it necessarily cacheable, nor does a URL represent an actual resource, just 'whatever that server wants to give you at that address now'. We have time-relative links, which are useful - but we should also have time-absolute links, which can be stored forever as long as anyone cares.
We'd still be at the mercy of whoever chooses to cache (or not) - but permanent data chunks would be a lot more cache-friendly for those who cared to do themselves. Debacles like the End of Geocities wouldn't be nearly as big a deal - it would still be cached wherever anyone had accessed it.
(This sort of idea of a precisely identified, perma-web rather than a 'whatever the heck the server wants to give you right now' web is pretty much what Ted Nelson's Xanadu was getting at, and has never really been implemented, at least not well.)
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Why can't someone build a purpose-built compression algorithm for URLs, so we can skip the URL shortener providers entirely? URLs contain lots of oft-occurring constructs, so I would think a reasonably good compression ratio could be attained.
Take a URL like http://is.gd/XXXXX - that's 18 characters where only 5 are being used to reference the URL. Couldn't a generic URL compressor do a better job on most URLs of reasonable length? Then we could build inflate support directly into the browser and skip the URL shortener entirely.
Maybe it's just me, but it looks like the AC meant the SMS system currently used in the USA, not the SMS system invented by the USA.
If Twitter is the main consumer of these, and they depend on them, why doesn't Twitter go into the shortening business? Buy one of those short domain names and run it themselves. They clearly have the resources, and the motivation. Seems obvious to me.
J