[Pre-RFC] DNS domains as package namespaces

kornel:

For example, we have openssl, boring, aws-lc, libtls and ring. They're all derivatives of openssl, but they're not the same "ssl" library. There are differences in their APIs and feature sets. There's also rustls, native-tls, schannel, security-framework, and superboring and smaller pieces overlapping with RustCrypto crates.

I agree that in your provided example, moving from openssl, boring, aws-lc etc to company-a.io/tls, cool-project.com/tls etc seems like a degredation in user experience.

I disagree that this is automatically the result (nor the goal, in my opinion) of the proposal though. Enabling something does not mean removing something else, and these crates will (probably) remain to be named as they are.

However, namespacing would allow me to publish a patched version of any of those (which I would never do for a cryptography-related crate, I know my limits ). And it would be really clear I am using my patched version because I'd likely publish it as my-website.nl/boring. It would make it immediately clear that this is mine, not the official version. Just like if I were to publish it as jarrovgit-boring today with a lib.name = boring. The difference to me is that the namespace clearly conveys identity association, while using the currently possible workflow (lib.name) is only by convention.

Enabling publishers to name their package to the crate's domain (e.g. my-website.nl/xml, where the previous mentioned "domain" refers to xml in this example) does not make it required to do so. Just like all of the openssl, boring and aws-lc package owners could already name their libraries tls with their wildly different APIs and confuse everybody. They are not doing that today and I don't see a reason for expecting this to happen when such a proposal as this would ever see an implementation.

kornel:

There are some benefits to having extra identity and flexibility in naming, but ability to remove distinction between implementations is not a benefit, but a confusing downside of the proposal.

TL;DR of my reply: this is not an added confusion, this is current behavior already through the existence of lib.name.