As a user the most frustrating part isn't waiting for the page to load (due to the third party) but just not knowing where I'm going. URLs have gone from being cryptic to being titled seo/human friendly to cryptic again. I like knowing the title of an article before I click on it.
This is why I implemented url following on the server in Mibbit...
Having someone throw you a shortened url on IRC is a pain, so now the Mibbit server follows it, and sends over the destination URL, which shows when you hover over the shortened URL.
Means a few less surprises ;)
I've seen a couple of other sites do something similar, although it's usually an (expand) thing you have to click.
Perfect, that's what everybody should do, just replace the unreadable cryptic shortener with "link" and follow the url so hovering will show it on the status bar.
Well, for our site, tinyarro.ws, all URLs are all automatically previewed so you have a chance to decide. So if you can get over clicking silly unicode URLs, you should feel more comfortable. http://➔.ws/this
I'm a big fan of informed consent, and I don't understand why the other URL shrinkers don't do opt-out previewing rather than requiring people to track down some mysterious preview cookie or preview URL syntax.
One reason other URL shrinkers don't do opt-out previewing is because it defeats the purpose of the shrinker being convinient. For instance, I use bit.ly's plugin in my Gmail inbox. In two clicks, my URL is shrunk and pasted wherever I want it. If I had an automatic preview of the page, it would take longer to load, making the shrinking process less convenient.
True, but it is entirely opt-out with a single click. So it doesn't have to be there-- but for your clickers they can decide for themselves what they prefer.
We didn't make the problem. We're just having fun with silly URL hacks and giving people something fun to show their friends. While we're at it, we're trying to do it the best way we know how.
This comment suggests you don't understand my point. Which is basically that people will act in their own individual interest even when its obvious that if everyone does the same thing, bad things are the inevitable result.
this comment is unbelieveably snarky, if it were anyone other than joshu I have a feeling they'd be at -4 right now, not +4. Would you really say "want a medal?" in person. I doubt it.
Well, it's different information. It is nice to know what it's about, but I'd rather read a random news.ycombinator link than a random article titled "Do Tiny URLs Suck".
I wrote shorty (http://github.com/bradgessler/shorty/tree/master), installed it on heroku.com, and hooked my own URL up to it so I could enter concise, descriptive shortened URLs. Its not for Joe Shmoe but if you're a geek, check it out.
Really, it makes that problem worse. I've had it burned into my brain what a shortened URL looks like - short domain, short hash - so I can immediately recognize one and be suspicious of it. But looking at http://tinyurl.com/Do-Tiny-URLs-Suck, I may just click without realizing what it actually is.
And, of course, there's Twitter's useless implementation of auto-shortening, which occurs after you submit, thus the 140 limit applies to the original URL.
>political censorship pressure on the URL-shortening service
Couldn't this be mitigated simply by establishing credibility for a given service, in the sense in the sense of making it known to be hosted outside politically supressive jurisdictions or by parties resilient to political pressure? For example, I would trust a URL-shortening service hosted by The Pirate Bay or Wikileaks to be free of political censorship.
Well, then you've got bigger problems than URL shortening. I don't mean to be flippant; if you're in that kind of country then maybe you can't even trust your normal DNS.
my point (and i think that of the person you originally replied to) was that if you have to go through a url-shortening proxy to get to a page that is not blocked, but the url-shortening site is, you will be blocked from accessing a lot of content simply because you don't know its real url.
Ah, perhaps I misunderstood. I thought political censorship pressure meant the government pressuring the URL-shortening service to change the target of short URLs that people try to use to point to politically disagreeable content.
Or if your school's webfilter blocks tinypic and some of the other url shorteners. It's one of the most annoying things about trying to read tweets or reddit these days.
A stateless url shortening service using a compression algorithm that is published (both the algorithm and the codebook used for compression) can mitigate almost all this problems:
* Browsers can decrypt the URL on the fly, just move the mouse pointer over the shortened URL and you'll see the full URL before to click.
* The DB can't get lost. There is no DB
* There is no single point of failure, everybody can run the service, the full information is inside the shortened URL.
* If this gets integrated into the major browsers, there is no a round more of lookups and there isn't possibility of DoS if the service(s) are attacked or offline. At max you can't create new shortened URLs. But remember? Everybody can run the same service.
It will not be possible to be as effective as stateful services, the URLs wil be a bit bigger, but the gain in reliability is huge.
Edit: and p.s. seriously SMS are not good for real message exchanging and will almost die in short time. This is not an issue, nobody really need URL shortening.
I don't think a compression algorithm is going to work. Compression rarely works on such short texts and most URLs are already very dense in information per character. Also, URL shorteners have to stay in the URL-safe character set, and the final product has to have a URL format.
I tried gzipping a Google Maps directions URL and then outputting that in base64. Results:
$ wc -c url*
217 url
186 url.gz
252 url.gz.base64
So the compressed and then base64'ed version is actually longer. And of course it's more opaque. And I haven't even added on some http://some.domain/ at the beginning to make it URL-like.
This doesn't even work in theory, let alone the practical impossibility of getting every http-fetching service to adhere to this scheme.
Hello. Gzip is not the way to go, try 'Smaz' and you will get better results, but I'm going to write a specifically tuned version of Smaz in order to work very well with urls.
I'm doing this work for Redis (another project of mine) but I guess that somebody else can exploit this work in order to build a stateless url shortener service. I hope so at least.
I don't know much about this sort of compression, but there are some pretty long urls out there. Reducing a four-line Google Maps url to one line would be an amazing achievement, but it doesn't seem like it's quite enough for what people do with reduced urls today.
How about we build a standard communication mechanism for websites that shorten urls and builders of sites that allow people to use them. Here's what I propose
From the builder of the shortners' perspective, they need to provide an API that can be used by the builders to extract more information about the link.
So, if you paste http://short/letters into this window, pg could go to the url http://short/letters/fullurl and that would return a string that contains the full url corresponding to that short url.
There could be a list of other options that could follow along like that and provide more information about all urls managed by the short urls. There could be screen shots of the site behind it. If you hover over it, you could pop up a tool tip with details about the url, who created it, when, what the title of the page is, the keywords and descriptions.
In a way we are replicating how the human brain stores information. Each nucleas of the nerve cell stores information about how it was built in the form of DNA, that's the code we write. There are long fibers that extend from the nucleas out to other networks of neurons. They supply electricty, pulses of light, and arrangements of magnets on little spinning disks and wafers of silicon.
What we need is a open standard for URL shorteners - where the shortener can publish the time-to-live of the URL, and other stuff (that I really don't know about, but I'm sure some netOS guys can come up with). This way they are transparent, and systems like archive.org and search engines can simply remove the layer of indirection in their systems. Of course, shorteners may not want that to happen, but there needs to be a way to gracefully transition to the direct link in long-term archives. Perhaps the system could even negotiate that time before removing the middleman.
Of course, services like Twitter could allow <a href> tags (I do not know if they do; I do not use Twitter), which would help a lot in allowing users to save space while posting links.
This is really interesting. One using a URL shortener is essentially setting up a parallel DNS infrastructure (like the article said). And there is nothing preventing anyone from doing exactly this right now. One could run a DNS that re-maps any name to any desired IP. The new root "just" have to get people to put down your servers instead of the ones that their ISP or organization gives out.
This is usually frowned upon by the W3C Tag... as I know from experience on the XRI TC... becuase XRIs use an alternate resolution process. However I've created shortxri.net which shortens URL's to an XRI, which can then be used as relative URLs. Now one can tack an XRI on any domain which supports XRI resolution, and you can push the XRDS (which the XRI ultimately points to) to other domains as well. So the xri @si348u can be attached to http://shortxri.net/@si*3*48u or http://xri.net/@si*3*48u or the even shorter http://xri.be/@si*3*48u to all resolve to the same place.
XRIs don't even have to be just URLs... and logging in with OpenID gives you even more options.
This is a idea I've had for a while that solves the short-url problem... with a bit of work.
I call it ^url
It would work like DNS servers.. replicating the content between each other (the map between fullurl -> shorturl). You submit the sortURL to any one of the participating services, and that server will push the new url to all the others servers as well.
A browser extension would make any ^url (yes anything starting with a ^ symbol) and the browser would be configured to use any one of the servers (just like how you would use a domain name). You can make it so a mouse over will resolve the ^url and show the linking path (solving yet another issue).
I wish I had a bit more time these days to dedicate to this...
Seems like something that could be fairly easily solved by proposing an extension to the DNS spec - making it ICANN operated public infrastructure might not be a good thing, though but it seems right from a technology perspective.
He didn't really say anything new - it's all very obvious stuff.
The most obvious thing though is what he didn't say: no one cares. I mean, despite all these drawbacks and the so few advantages to link-shorteners, no one is doing a damn thing to stop them. And new ones keep coming up every day.
I believe soon we will have web sites which block visiters coming from shortened URLs, as sites will not be able to distinguish natural traffic from spam clicks.
That's silly, you don't turn someone away because you can't properly fit them into your metrics. "Unknown" on a traffic graph is better than just cutting out that piece entirely.
