livekit: Bump rustls to 0.23 indirectly and allow consumer to provide TLS config#916
livekit: Bump rustls to 0.23 indirectly and allow consumer to provide TLS config#916kubkon wants to merge 3 commits intolivekit:mainfrom
Conversation
79cae95 to
8a5a327
Compare
Otherwise, when using livekit client SDK aka the `livekit` crate we are pulling in `webhooks` and `access-token` related functionality which really is not needed.
|
FWIW here's a matching PR on our end: zed-industries/zed#50205 Thought it might be useful to showcase the intended use of the proposed changes! |
|
Thanks @kubkon! This generally looks good to me. One concern: instead of changing the default features on livekit-api, could we instead set |
Yep, makes sense! I think I actually started with that one but was on the fence which route would be better. Will fix! |
|
Actually, @ladvoc, I remember now why I went with the current approach - setting |
This patch does two things:
rustlsto 0.23 used indirectly viatokio-tungstenitebumped to0.28andtokio-rustlsbumped to0.26tls_config: rustls::ClientConfigfield to the consumer inlivekit_api::signal_client::SignalOptionsandlivekit::room::RoomOptionswhich is then internally routed to theSignalStreamwhen configuring the connection; setting this option requires buildinglivekitwithsignal-client-tokioandrustls-tls-native-rootsfeatures enabledlivekit-apia little sincelivekitas a client SDK doesn't needwebhooksoraccess-tokenwhich ends up pulling in unnecessary deps such asjsonwebtokenand ends up conflicting with our use ofjsonwebtokenin other places in Zed - lemme know if that makes sense or if there is a better way!With this patch upstreamed, we could get rid of our fork over at Zed. Lemme know what you reckon!