RFC: Interclip codes as substrings of hashes

[filiptronicek]

Hi, all! Filip has ideas, and it is only suiting, for the next generation of Interclip to feature brand new things, here's one I produced today, and I would love to hear your thoughts!

After revisiting an idea from an interview to STC I figured why not make Interclip codes not random? They could be 5-letter substring of a sha256 hash of the URL itself, making codes immutable even after their expiration. Maybe we could also use sha1, like git does, with tools like GitHub mostly showing just the first 7 characters of codes (it is possible to have reliable hashes with 5 characters? What about collisions?)

[filiptronicek]

Idea about collisions: if two hashes are the same (obviously not hashes, but their respective substrings), just use more characters, producing 6+ character codes, which would have to be accounted for in all Interclip clients.

[filiptronicek]

Here are the numbers of permutations versus the length of the code:

[filiptronicek]

A big plus of this approach is that the client would know the interclip code even before sending the API request, making code resolutions instantaneous (local is always faster than a CDN). We could also enable autocompletions on 4 letter codes if there's only one matching the first 4 characters of the hash.

[bigint]

sha1 to 512 is not as performant as a random string 😄 they need more memory to compute it!

Even its 10 times slower than md5 🤣

[filiptronicek]

Is that noticeable when hashing 100- character long URLs?

[bigint]

Yes ofc, the hashing is not based on the data, the speed is decided in the hash function 😄

[filiptronicek]

This is now fully implemented, thanks for all the input!