Regarding Cargo.lock, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock should definitely be tracked too [1][2].

It’s strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of --locked not being the default behaviour of cargo install, giving a false sense of security/reliability/reproducibility. But “false sense” is never a good technical argument in my book.

Anyway, your crate is an application/binary one. And if you were to not change the "*" dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock ;)

• Don’t use "*" dep version requirements.
• Add Cargo.lock to version control.
• Why read to string if you’re going to base64-encode and use Vec<u8> later anyway?

Sort by “best” is coming to Lemmy, in case you didn’t know.

Don’t know if this will be relevant at all, but I’m almost hoping this will force Lemmy devs to abandon the obscure markdown crate they use for pulldown-cmark.

Using an obscure markdown implementation just because it supports spoiler tags always sounded like a silly decision to me!

I won’t be able to fully replace it, I’m afraid. Not before communities gain the ability for their posts to not show up in high traffic feeds.

Some subreddits I follow have this set, but this is not yet implemented in Lemmy if I’m not mistaken. So a workable move to Lemmy for them is not possible at this moment.