Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

urizip-dot-populace-soho.appspot.com

Post reply on HN
Print view View original

81–87 of 87 posts

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

#81

Post by 19eightyfour »

grey-area wrote: post #79
19eightyfour wrote: post #62

Earlier quoted context omitted.

This is so cool. I realize this might be some sort of a joke, even if the specification part is actually something you're working on! Stranger rfc's have happened right? But I actually think something like a binary format for URLs that tries to be a space efficient as possible is pretty useful. At least it's something that I want. That's some of the idea that contributed to me trying to make this.

It was a little joke I'm afraid, because you can't reverse the hash, so you need to store it somewhere. Most of the existing link shorteners are a variant on this idea. There are RFCs I think about content addressable storage if you're interested in that sort of thing, this is sort of like content addressable addresses if you see what I mean :), and someone else mentioned a distributed hash table, which is an interes…

Yes, you totally understand this. This is a little bit like content addressable. :) Thank you for commenting, if you have any ideas about how to improve it I invite you to submit an issue or PR!

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

#82

Post by 19eightyfour »

a3n wrote: post #37

http://fnord.com => gR30sacA but http://gR30sacA !=> http://fnord.com gR30sacA => http://fnord.com There's nothing about gR30sacA all by itself that tells me that this is a shortened URI.

If you've got some ideas about how to improve it please submit an Issue or PR! Thanks for commenting!

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

#84

Post by 19eightyfour »

tghw wrote: post #29

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

I want to point out that yes, even tho it's longer than the URI by 2% , it is shorter than the Base64 encoding of the URI by 24%

For high entropy URIs with long identifier sections, this is common. While we may exceed the length of the original URI, we are almost always shorter than the Base64 version.

And this is just the first iteration of this algorithm. I think we can do better when we introduce some new ideas that people have suggested and are already in the works!

Thanks!

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

#85

Post by 19eightyfour »

19eightyfour wrote: post #64
Hansi wrote: post #31

Doesn't support anchor links it seems: Encoder https://calendar.google.com/calendar/render#main_7 kF9DKUm9hMdDPUOCFu-QohzySQDx6pLN Decoder kF9DKUm9hMdDPUOCFu-QohzySQDx6pLN https://calendar.google.com/calendar/renddabD

Oh, that's a bug! Thank you. Fragment links ought to work. I'll open an issue. Issue: https://github.com/dosaygo-coder-0/urizip/issues/1

Okay fixed now! https://github.com/dosaygo-coder-0/urizip/compare/4b5be28......

Thanks for report :)

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

#86

Post by 19eightyfour »

stevekemp wrote: post #22

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!

Okay I think this is fixed now! https://github.com/dosaygo-coder-0/urizip/issues/4#issuecomm... Thanks for report. Please reopen if still happens, thanks! :)

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

#87

Post by 19eightyfour »

peeters wrote: post #32
dafrankenstein2 wrote: post #21

Earlier quoted context omitted.

an analysis can be done on that

You're right. I don't have the resources for a full analysis but I did "shorten" three Google Maps links (IMO a good candidate for link shortening). The compression for the three ranged between 114% and 117% of the original. E.g.: https://www.google.ca/maps/place/Rockefeller+Center/@40.7586... Encoded: k:Yr5fL7YTHQz1AlBxKJrphUT0qAgf6ouSZ3Ze1yEQCNiTlmLclpycllFbllYTkxZcnJyY1hFTE0dUfkwV5SlgdREpEKLCUxjsWlLA6xpSJFMQx7EksQ…

This URI has a lot of hex sections and numbers in it, and I'd like to point out this is still 85% of the Base64 encoded version of that URI, even tho its 114% of original.

I think we could get this size down below parity by encoding the numbers and hex sections.

Thanks for the comment! If you have some ideas how to improve the compression, I invite you to please submit an issue or PR, thank you very much.

Post reply on HN