Show HN: Shortern URIs using Huffman Coding, not a database • Hacker News Board

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#21

Post by dafrankenstein2 » Tue, May 02, 2017, 7:14 PM UTC

peeters wrote: post #16

mytherin wrote: post #15

Earlier quoted context omitted.

The end-game of the idea is that the decoder becomes embedded into browsers, so URLs can be shortened without requiring users to go through a third party service that tracks you. This method would be both faster than current URL shorteners (because it all happens client side - no extra round trip required) and much more suitable for archiving purposes (no single-point-of-failure that takes down millions of shortened…

Hmm, IMO it should be a valid URL with a protocol then. Something like zurl:Ma0t7asf...0a==. Something needs to identify how to handle it. I'm really not sure it's handling what URL shorteners are though. URL shorteners can take uber long URLs, like 150 characters, down to 10-20 characters. Huffman coding might be able to get that down to 120 characters, given how much of many long URLs is already random data that is…

an analysis can be done on that

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#22

Post by stevekemp » Tue, May 02, 2017, 7:16 PM UTC

I'm seeing errors:

    ReferenceError: urizip is not defined
       decoder.onsubmit()

Shame. I did consider using a DHT for storing shortened URLs once upon a time, to avoid the single point of failure. These days I guess there is already somebody trying to sell a solution using a blockchain!

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#23

Post by pmiller2 » Tue, May 02, 2017, 7:20 PM UTC

I came up with a variant of this idea in an interview once. It did not go over too well. :)

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#24

Post by anon1253 » Tue, May 02, 2017, 7:27 PM UTC

Here's a silly trick we used for a similar problem: use zlib with a custom compression dictionary. Our application had tons of interlinks (think linked data) that we wanted to expose to the end user, but putting urls in urls is kinda ugly. So we ended up with our own custom compression dictionary and pushing them through zlib. Works like a charm.

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#25

Post by gumby » Tue, May 02, 2017, 7:27 PM UTC

Nice! By making it algorithmic and serverless the client could even expand it in situ when the mouse hovers over the link.

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#26

Post by asimpletune » Tue, May 02, 2017, 7:30 PM UTC

pmiller2 wrote: post #23

I came up with a variant of this idea in an interview once. It did not go over too well. :)

What was the feedback the gave you?

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#27

Post by aqme28 » Tue, May 02, 2017, 7:41 PM UTC

matt_heimer wrote: post #13

ageitgey wrote: post #2

The url for this post is 45 characters: https://news.ycombinator.com/item?id=14245119 If you encode it with this shortener, you get this 35 character string: mNb:w9iIp7u8di:AKB2xrPUVYUFhfRUWHwA Assuming you were using this string as a key in a shortening service like this: https://short.url/mNb:w9iIp7u8di:AKB2xrPUVYUFhfRUWHwA ... you'd end up with a url longer than the original url! So it's not technically a url shor…

I think you missed the part about it being serverless. I think the idea is to integrate the logic into the client.

But what's the benefit to turning a readable url into an unreadable one that's only about 3/4 the size?

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#28

Post by Crespyl » Tue, May 02, 2017, 7:53 PM UTC

peeters wrote: post #16

mytherin wrote: post #15

Earlier quoted context omitted.

The end-game of the idea is that the decoder becomes embedded into browsers, so URLs can be shortened without requiring users to go through a third party service that tracks you. This method would be both faster than current URL shorteners (because it all happens client side - no extra round trip required) and much more suitable for archiving purposes (no single-point-of-failure that takes down millions of shortened…

Hmm, IMO it should be a valid URL with a protocol then. Something like zurl:Ma0t7asf...0a==. Something needs to identify how to handle it. I'm really not sure it's handling what URL shorteners are though. URL shorteners can take uber long URLs, like 150 characters, down to 10-20 characters. Huffman coding might be able to get that down to 120 characters, given how much of many long URLs is already random data that is…

A hip solution would be to generate a short random name and then use something like Namecoin to distribute/lookup the matching value.

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#29

Post by tghw » Tue, May 02, 2017, 7:56 PM UTC

I tried:

    https://github.com/dosaygo-coder-0/urizip/commit/cb2bfd2e04e8b814943e42a5bf87eeff31a77126

Got

    kl9oo67XTkQCETxduLJSW5iUfSNh5pW6iDuhqKmzprOoJCaUYmMo5M7kiMaYxrBRjTQsWzqDks9BlBQWEQKsrKImrQU

Which is longer.

Also "OK" isn't a great commit message for almost every commit:

https://github.com/dosaygo-coder-0/urizip/commits/master

Re: Show HN: Shortern URIs using Huffman Coding, not a database

#30

Post by discreditable » Tue, May 02, 2017, 7:56 PM UTC

no_gravity wrote: post #7

Often urls can be most effectively shortened manually. I wish everybody who sends me something like this: https://www.booking.com/hotel/fr/hotelwestminster.html?label=gen173nr-1FCAEoggJCAlhYSDNiBW5vcmVmaDuIAQGYATHCAQN4MTHIAQzYAQHoAQH4AQKSAgF5qAID;sid=9b4fe19e9de68a3cb71714046bf9d64a;checkin=2017-05-12;checkout=2017-05-13;ucfs=1;highlighted_blocks=5190001_91458119_0_2_0;all_sr_blocks=5190001_91458119_0_2_0;room1=A;hpo…

Amazon is another great example.

    https://www.amazon.com/Cat-Facts-Marcus-Schneck/dp/0880295589/ref=sr_1_1?ie=UTF8&qid=1493754913&sr=8-1&keywords=cat+facts

can become

    https://amazon.com/dp/0880295589/