Maybe you're misinterpreting me, because the linked post suggests that bit.ly isn't actually doing what I am suggesting.
My proposal is this: when a user submits a link to bit.ly to be shortened, bit.ly follows the link through 0..n redirections until it finds the final endpoint URL. This final endpoint URL is then stored as the bit.ly link.
Of course, this assumes that you don't care about the modifiable destination redirects in the chain, which maybe you do. In this case you would only follow redirects which match a whitelist of followable domains (other link shorteners).
Maybe (probably?) there's something I'm missing that makes this infeasible, but it seems like the most logical solution to me.
My proposal is this: when a user submits a link to bit.ly to be shortened, bit.ly follows the link through 0..n redirections until it finds the final endpoint URL. This final endpoint URL is then stored as the bit.ly link.
Of course, this assumes that you don't care about the modifiable destination redirects in the chain, which maybe you do. In this case you would only follow redirects which match a whitelist of followable domains (other link shorteners).
Maybe (probably?) there's something I'm missing that makes this infeasible, but it seems like the most logical solution to me.