one of the main annoyances w/ base64 is when you want to it in the context of URLs

https://en.wikipedia.org/wiki/Base64#URL_applications

> Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' becomes '%2B', '/' becomes '%2F' and '=' becomes '%3D'), which makes the string unnecessarily longer.

I recently wrote a base64 encoder/decoder at work. Luckily, I did not need to make it compatible with other base64 encoders/decoders because, as the article points out...

> Base64 has eleven encoding variations that lead to confusion among developers on which variety of Base64 to use.

Each variation has its own niche (URL safe characters, filename safe characters, checksum support, etc). I see Base58 as basically just another variation of Base64 with its own niche (human friendly characters).

There's no need for existing apps to "convert". If their current Base64 implementation is good enough, they'll stick with it. Base58 is just another variation to consider when developing something new.

This is not the purpose of base58. The main use case for base58 is to avoid human error in similar looking characters ("l" vs I" or "0" vs "O").

As an example, this is used in Bitcoin addresses to ensure you don't accidentally type the wrong characters if copying an address by hand.

Base58 has existed for over a decade now, so I wouldn't exactly call it a "new" format at this point. And I've been using it for almost that long, so it's old hat to me.