Daniel McCarney

@djc WDYT about something [like this approach](https://github.com/rustls/rustls/compare/main...cpu:rustls:cpu-acceptor-plaintext?expand=1) as an alternative? I tried to come up with an adjustment that wouldn't break semver, so it's a little bit more awkward than...

I think based on the conclusions in #1915 this won't be necessary. I'm going to close it for now.

@Mubelotix Are you interested in trying to achieve the broader changeset Ctz described above?

> I only have experience with wasm in the browser though, so that's what the example would be about Personally my understanding of the general ecosystem here is lacking, but...

I think it's fair to close this for now while we wait on a reworked version closer to the goals Ctz outlined in [his comment](https://github.com/rustls/rustls/pull/1921#issuecomment-2078940118). Feel free to re-open once...

:wave: Thanks for filing this detailed issue! I think in general since the unbuffered API surface is so new it hasn't seen a lot of downstream usage and feedback on...

I'm not sure that we want to link the `ProducesTicketer` implementation into the `CryptoProvider` struct as a field but I'm curious what others think. :thinking: There's not really a "default"...

> I had too many panics due to enabling the two features together. Right, if the two options are enabled together, and no explicit default has been set, and someone...

> Similarly, if the same could be applied to CryptoProvider::from_crate_features, as I feel its current API can be too footguny. I think changes to how default crypto providers are constructed...

> rustls / Check semver compatibility (pull_request) Failing after 44s Just wanted to note IME this job always fails when there's a cargo patch in play, so don't worry about...