Hacker News Reader

Comment by roryokane | Hacker News Reader

Shortly compresses the text using the DEFLATE algorithm (http://en.wikipedia.org/wiki/DEFLATE) followed by Base64 encoding (https://en.wikipedia.org/wiki/Base64) before storing it in the URL. Base64 increases the size of data by 33%, but DEFLATE usually decreases the size by more than that. Thus, the link will usually be shorter than the content.

View on HN

I'm sure it will be somewhat shorter than the content but it will definitely be in the same order of magnitude and likely within a factor of 2. A link that is half as long as its content is pretty unwieldy and will take non-trivial time to transmit at longer lengths. Sort of defeats the point of a link in the first place.

Yes. You might as well just send a gzip'd file directly. It will be higher compression than Deflate (or if not, use BZip or 7zip), won't have the Base64 overhead, and (gasp) won't depend on a web service to decode. It also has the distinct advantage of not being really friggin annoying.

In other words, this is entirely useless, except as an amusement. Because it's funny how useless it is.

Well, no. To people, a pastebin.com/asdovnasdofnvopdsisadvasdfgv link is just as unmemorable as a base64 encode of an actual 1kb code data. However, nowadays, if I have a 1kb snippet I want fairly securely shared, sticking it in a chat box isn't a problem.

Well, except that it's a web site. That's why I would be attracted to this: it's something that I can send to anybody and it will always, always work. No hassle.

True, as a service in that respect it's useful.

But it still seems a bit unreliable. Accidentally clip a character off the URL and you're basically screwed.

You could say the same about any computer generated (hashed) URL.

Gzip is just a container format around DEFLATE.

Reply on news.ycombinator.com