Proposal: utilize ES's _id field

[terinjokes]

Currently the URL shortener generates a random ID until it finds one that is unused. It might be better to use the unique _id field, along with a reverseable hash, like the hashids package.

[keithamus]

I really like this idea! Some positives:

• While _id is sequential, hashids converts them into something which is much harder to reverse engineer. You'd need to guess the salt 👍
• I like that hashids outputs begin quite short - at just two characters 👍
• The risk of collision with manual IDs seems very low 👍 for example decoding a word like foo will likely return an error, which means we can then just go and do a database lookup for that manual id.
• there's ports to many different languages including JS and Bash! 👍
• I guess there is a theoretical maximum, but generating an ID of 9007199254740991 works fine.

Some negatives:

• hashids quickly go beyond 2 characters 👎. With the standard keyspace (a-zA-Z0-9) character set an id of just >50 is a 3 character hash, id >1936 is a 4 character hash, 85184 is a 5 character hash. Making a case insensitive keyspace (a-z0-9) shortens this dramantically more (>24 is 3 char, >576 is 4 char, >13824 is 5 char)
• if you lose the salt it'll be very difficult to get it back, and all those URLs you have suddenly break 👎 👎

[keithamus]

Thanks for your suggestion here @terinjokes! I think we'll look into implementing this on Jan 7th or Jan 8th!

[terinjokes]

Unless I'm misreading the code here, I think the current implementation would also go beyond 2 characters pretty quickly: if it can't insert with the random id it chooses, it will append a new random character and try again.

To farther reduce conflicts, it might be worth considering putting manually generated URLs on another path, eg: /m/foo. Sure it makes them longer, but manual tends to be composed of words anyways.