The document discusses the increasing focus on Rust for improving memory safety in the context of various technologies, such as Hyper for HTTP protocols and Rustls for TLS. It highlights several experimental components and suggests that component-based memory safety approaches are not widely embraced. The document also touches on future developments and API compatibility efforts related to these technologies.

1. 2024
rust in curl

2. memory safety is all the rage
hyper for HTTP/1 and HTTP/2
rustls for TLS
quiche for QUIC and HTTP/3
component-based gradual memory-safetyfication
does not seem to be very popular they are all EXPERIMENTAL
does it actually help?
@bagder

3. libcurl backends
libidn2
winidn
threaded
c-ares
sync
libssh2
wolfSSH
libssh
application
Public API
libcurl
HTTP
HTTP/3
TLS
SSH
IDN
Resolver
Content encoding
brotli
zstd
zlib
= just one
= one or more
Hyper
built-in
nghttp2
msh3
nghttp3
quiche
BearSSL
AWS-LC
GnuTLS
mbedSSL
OpenSSL
Schannel
wolfSSL
Secure Transport
rustls
BoringSSL
libressl
AmiSSL
OpenSSL

4. @bagder
future

5. hyper: drop or carry on
ISRG might have engineer working on it “soon”
@bagder

6. rustls
going for OpenSSL API compatibility
could potentially mean less work for us
@bagder

7. quiche
BoringSSL-bound
BoringSSL is...
Users?
@bagder

8. other?
IDN
SSH
compression
resolver
split off core parts?
what else?
@bagder