A few ideas:
1. unicode URLs. Throw some emojis in there. A side project plan of mine has been to run an emoji link shortener service.
2. Another way would be to store it on the blockchain for a publicly verifiable lookup.
Show HN: Shortern URIs using Huffman Coding, not a database
11–20 of 87 posts
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#12I don't really understand the motivation here, care to expand on that?
A url shortener like tinyurl maintains a database of original urls linked to the shortened versions. Only they can translate between them, so 1) there's a risk the links will die if they die and 2) there are tracking implications.
This shortening scheme simply uses lossless data compression, like a zip. As long as the decompression algorithm is available, the link can be translated by anyone.
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#13The 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.
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#14I don't really understand the motivation here, care to expand on that?
A url shortener like tinyurl maintains a database of original urls linked to the shortened versions. Only they can translate between them, so 1) there's a risk the links will die if they die and 2) there are tracking implications. This shortening scheme simply uses lossless data compression, like a zip. As long as the decompression algorithm is available, the link can be translated by anyone.
You can click on a tinyurl link. That's all that's required from the user.
I'm finding it really difficult to understand where this would be useful. Do we expect everyone to keep the handy decoder available and know to use it when they see random base64 encoded strings?
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#15Earlier quoted context omitted.
A url shortener like tinyurl maintains a database of original urls linked to the shortened versions. Only they can translate between them, so 1) there's a risk the links will die if they die and 2) there are tracking implications. This shortening scheme simply uses lossless data compression, like a zip. As long as the decompression algorithm is available, the link can be translated by anyone.
You can click on a tinyurl link. That's all that's required from the user. I'm finding it really difficult to understand where this would be useful. Do we expect everyone to keep the handy decoder available and know to use it when they see random base64 encoded strings?
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 URLs).
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#16Earlier quoted context omitted.
You can click on a tinyurl link. That's all that's required from the user. I'm finding it really difficult to understand where this would be useful. Do we expect everyone to keep the handy decoder available and know to use it when they see random base64 encoded strings?
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 largely incompressible (past the reduced character set).
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#17I don't really understand the motivation here, care to expand on that?
A _lot_ of shorteners die, with millions of links dying every day [0]. This method would be reproducible, so they'd never die.
[0] http://archiveteam.org/index.php?title=URLTeam#Dead_or_Broke...
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#18A few ideas: 1. unicode URLs. Throw some emojis in there. A side project plan of mine has been to run an emoji link shortener service. 2. Another way would be to store it on the blockchain for a publicly verifiable lookup.
Re (1) - that's linkmoji - http://www.xn--vi8hiv.ws/
So the URl for this discussion becomes http://linkmoji.co/⭕ or http://xn--k7i.ws
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#19I don't really understand the motivation here, care to expand on that?
A url shortener like tinyurl maintains a database of original urls linked to the shortened versions. Only they can translate between them, so 1) there's a risk the links will die if they die and 2) there are tracking implications. This shortening scheme simply uses lossless data compression, like a zip. As long as the decompression algorithm is available, the link can be translated by anyone.
Maybe we could store the translation of shortcode -> full URL on the blockchain
Re: Show HN: Shortern URIs using Huffman Coding, not a database
#20Often 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…
Oh, but distributing links with tracking tokens attached is a really great way to mess with sites that track users: Well, we've had one user who really liked the new content. They viewed it 15,323 times... waaaaaait, damn it!
nice entertainment