feature request - base58 d/encoding about data-encoding HOT 2 CLOSED

Thanks for reaching out with your question!

Quick answer

No, base58 doesn't fit the goal of data-encoding.

Longer answer

You might be interested in using multibase which provides 2 variants of base58. It depends on data-encoding and base-x to provide those different base encodings. That said, if your concern is the crate getting updates, that won't be an option for you either. But I'd say that looking at most recent crate update is not an important decision factor for such trivial libraries. Base conversion only needs to be written once and it stays correct. Usually those crates only get updates to provide more Rust-y interface or convenience, but the core logic is really the same and won't change. All those crates (multibase, base-x, and base58) seem to have approximately the same number of downloads, so I guess picking any of them should do.

More context about data-encoding's goal

This library only provides base conversion for powers of two fitting within ASCII (namely 2, 4, 8, 16, 32, and 64) because those are streamable encodings, which is necessary when the input length is unknown. Encodings like base58 don't have this property and can only realistically encode short inputs (which is fine for bitcoin and such). That's quite a different usecase. Maybe one day data-encoding may also provide something for those usecases, but right now this is not planned.

from data-encoding.

@ia0

First, thank you very much for the comprehensive answer and the full context provided.

Everything makes sense.

• You are correct; the fact that the narrow base58 crate has not changed for a while is probably completely fine, given its narrow scope and the nature of its function.

• Thank you for the context about the "power of two" aspect of data-encoding. It makes total sense not to make any exceptions and to keep the crate focused. I definitely value focused crates, so this is very good to hear.

from data-encoding.