No. Not only is Sodium (more accurately: NaCl) not a TLS library, but it doesn't even implement the primitives that TLS needs; it can't really even serve as a component of another TLS library.
Not that you're not absolutely right about NaCl & Sodium, but isn't the GP talking explicitly about Sodium and not NaCl?
When you say 'more accurately: NaCl', is there something particular you're getting at, or are you speaking from experience of NaCl rather than Sodium (or are you talking about the fact that the bindings seem to be named/built for the original NaCl?)
Edit: or do you just think it's still better to call it NaCl given that it's a fork of, or I suppose a refined implementation of NaCl?
Any SSL implementation worth its salt needs to implement historical primitives like RC4 and MD5. libsodium will not and should not implement these because they conflict with the goal of providing an idiot-proof crypto library.
Isn't it better to not include stuff that's insecure, even if they have historic value? Isn't this a big part of the problem of some (even OpenSSL) software?
it's more accurate to discuss NaCl since that's what libsodium is. NaCl is the combination of crypto primitives and the "box" abstraction. libsodium is just the repackaging and clean-up of the original NaCl implementation. If you're discussing crypto, you're going to be looking at the papers on NaCl.
