Most convenient feature configuration for a command that uses SSL/TLS libraries

When writing a Rust program that uses SSL/TLS (e.g., via reqwest), what configuration of SSL/TLS features is most convenient (in terms of both functionality and need for C compilers, libraries, etc. when building) to users installing the program? The best starting point would seem to be having one feature for using native-tls (including a separate feature for vendoring openssl) and another for rustls, but which one should be the default? If I (the developer) am also distributing prebuilt binaries of the program, which feature should I use for the binaries? Decision paralysis is not fun.

reqwest uses native-tls per default, although they designed their default-tls feature in a way that allows them to exchange the TLS backend with rustls in the future.

I'm not sure what the best approach is here, I never had to ship prebuilt binaries before. But I guess if you can avoid dynamically linking against the native tls implementation, your binary might be more robust and cause you less bug reports from people who couldn't execute your binary, because their TLS setup is a bit wonky. But then again, there might be better arguments for using the native TLS implementation anyway, I don't know.

It's kind of a non-answer, but is the scope of your binary small enough to distribute two versions for the different TLS backends? They may cause more confusion for users (not to mention a more convoluted build process) but at least the "doesn't work for me" case would have an alternative binary to switch to.

I'm not really sure what you mean by "the scope of [my] binary," but I use cargo-dist for building, and it doesn't seem to support providing multiple assets with two different sets of features.

Gotcha, that's unfortunate.

To clarify my meaning for scope: A narrow-scoped binary like wget or curl may warrant having two versions for SSL backends, whereas a larger-scope binary (like an IDE, which happens to also query the web sometimes) might not justify having two versions for two TLS backends.