71–80 of 87 posts
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.
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!
Nice! By making it algorithmic and serverless the client could even expand it in situ when the mouse hovers over the link.
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.
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
And if it was using compression to produce an encoding using unicode the first trouble is I'm not really sure how to do that encoding since Unicode is not straight up translating any sequence of bits into characters there are some restrictions and there's all kinds of rules I think and I don't really know how that works and I would like to keep it simple. And the second point is I want to keep it so it's very easy to transport which pretty much means we need to use base64 in my opinion.
I've got a suggestion for a better format called hurl, I'm working on the RFC as I write this. It's constant length , doesn't require database storage, avoids collisions and compresses longer urls far better than the huffman coding method. Here is the complete implementation (in go): func hurl(s string) string { sum := sha256.Sum256([]byte(s)) return base64.RawURLEncoding.EncodeToString(sum[:]) } https://play.golang.…
How do you decode the shortened URL to get the original back??!!??
If you use React with react-router[0] (or a comparable JS-based solution), you can just apply lz-string[1] to a stringified JS object and make the resulting string match a path. Then you need is some code to reverse the operation (lz-string -> JSON -> JS object). That's what I'm doing to create shareable state in an app I'm building for a research group. Done naively, it will have the same problems others mentioned h…
edit: I looked at your gist and this is a totally great idea. I see what you're doing, converting it to make it more compressible. Very clever. If you have some ideas about how to improve my compression in this binary URI encoder, please do submit an issue or PR! Thanks for commenting!
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
This specific URL has a long hex component for the commit hash.
We might be able to get that size down by encoding the hex string at the end into numbers. I'm working toward this in radix_coder.js[1]. I'll open an issue[2]. Thanks!
In tests of strings not URIs I got 68% of original for digit strings, and 90% of original for base36 strings, after encoding as numbers then into base64.
More generally I see rates of 70% to 90% for URIs that have a mix of words and numbers. And more than 100% for strings with lots of identifiers.
Eg:
https://www.citylab.com/housing/2017/05/the-new-suburban-crisis/521709/?utm_source=SFTwitter
And
http://www.saveur.com/chinatown-produce-prices
While
https://www.gov.uk/search?q=Grants&filter_organisations%5B%5D=hm-treasury
OK is not an informative commit message. Thanks for the prod. I'll open an issue.
Issue: https://github.com/dosaygo-coder-0/urizip/issues/5
And thanks for commenting! If you any ideas about how to improve the compression please submit a PR!
[1] https://github.com/dosaygo-coder-0/urizip/blob/master/radix_...
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…
Even a 1 letter host at a 2 letter tld like .co .in .ws .tk introduces 7 or 8 for the scheme, one for the slash, and 4 for the host. So a minimum of 14 to put it on a domain.
I haven't decided whether to put it on a domain or to use a scheme prefix like zurl: our something else.
The other possibility is this if not really about shortest, or Twitter, but more about, transport encoding and an efficient binary format, and something fun.
Thanks for commenting! If you have any ideas how to improve the compression or other things, please submit a PR!
I've got a suggestion for a better format called hurl, I'm working on the RFC as I write this. It's constant length , doesn't require database storage, avoids collisions and compresses longer urls far better than the huffman coding method. Here is the complete implementation (in go): func hurl(s string) string { sum := sha256.Sum256([]byte(s)) return base64.RawURLEncoding.EncodeToString(sum[:]) } https://play.golang.…
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.
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 interesting idea.
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…