# \[Pre-RFC\] Domains as namespaces **URL:** \ **Category:** cargo\ **Created:** [October 27, 2018, 12:00am UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688 "2018-10-27T00:00:07Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![anon2808951](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@anon2808951](https://internals.rust-lang.org/u/anon2808951)\ **Post date:** [October 27, 2018, 4:17pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/23 "2018-10-27T16:17:26Z")
(post deleted by author) ---
**Author:** ![pythoneer](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pythoneer/32/2010_2.png) [@pythoneer](https://internals.rust-lang.org/u/pythoneer)\ **Post date:** [October 27, 2018, 5:20pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/25 "2018-10-27T17:20:18Z")
It was addressed several times but i haven’t seen a convincing answer yet. One problem – and i believe its currently the major one – is “what if i loose access to the domain?” and the general answer was “its as bad as if you loose your github account”. But i don’t believe that, it is worse and a possible security concern. If i loose my github account, i can’t publish any new version of the crate – that’s unfortunate but fine. Lets imagine i have a domain “[usefullstuffforrust.com](http://usefullstuffforrust.com)” and i publish my important “is-even”, “is-odd” … crates here. Now nearly everyone uses my useful crates and they are among the most popular ones but they don’t need much maintenance because the crates are pretty much “done”. So over the years i lost interest in maintaining them but they don’t loose importance to the Rust ecosystem – i stop using and paying for the “[usefullstuffforrust.com](http://usefullstuffforrust.com)” so i loose the domain and its open for anybody to pick it up and publish new version of my crates? With added “features” like cryptominers and keyloggers? ---
**Author:** ![mbrubeck](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mbrubeck/32/174_2.png) [@mbrubeck](https://internals.rust-lang.org/u/mbrubeck)\ **Post date:** [October 27, 2018, 5:30pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/26 "2018-10-27T17:30:16Z")
**Moderator note:** Everyone, chill out. If you want to participate on this forum, you _must_ do it without sniping at other users. ---
**Author:** ![ethanpailes](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ethanpailes/32/4812_2.png) [@ethanpailes](https://internals.rust-lang.org/u/ethanpailes)\ **Post date:** [October 27, 2018, 5:53pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/27 "2018-10-27T17:53:25Z")
> There isn’t any. This is intentional, because doing this would be a terrible idea. > > Allowing people to refer to namespaces from within the source code would make it impossible to switch out unmaintained crates with maintained ones (who have been forked and live under a different organization) without having to touch every single source file. That's an atypical understanding of namespaces. Not that it is necessarily bad. I think the ability to swap out unmaintained packages for maintained packages has a certain appeal, but what you are proposing does run counter to what people will be used to. In particular it is not what the other main domain-based namespacing system does (the JVM ecosystem). It is also not how npm scopes work. Including namespaces in how you refer to packages in code is the standard way to do things. Calling it a terrible idea out of hand is unjustifiably dismissive. The position that conflicts won't happen much and when they do you can just use crate renaming is an interesting one. It has the benefit of keeping the language the same. I really like the idea of keeping the changes confined to the package manager. ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 27, 2018, 6:08pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/28 "2018-10-27T18:08:50Z")
If you go federated, you can sign packages and cargo can verify the signatures. The server signature would be stored somewhere like .well-known, and cached locally both in [crates.io](http://crates.io) and in Cargo.lock (or maybe a Cargo.sig – we don’t wanna leave out library packages!). This means if a domain changes ownership, this won’t lead to a potential security issue. Ofc, it provides little to no protection against that domain/server being hacked, and servers are generally easier to hack than a crate developer’s computer. This is one point where a centralized registry is beneficial - if you have many registries, it’s likely that at least some of them will have security vulnerabilities. If you have a centralized registry, it’s a lot easier to patch those vulns. In any case, federation wouldn’t necessarily make the attack surface any smaller - [crates.io](http://crates.io) would still be a single point of failure, as it’d be the default registry. If the ability to use alternative registries takes off, tho, it _could_ lead to a smaller attack surface, as different registries could be using different software with different vulnerabilities or even a strong layer of hardening. Some registries could even be served over static pages + a cron job that checks for updates, making hacking them quite a task! ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [October 27, 2018, 6:15pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/29 "2018-10-27T18:15:12Z")
Maybe this is a tangent, but this term "federated" has shown up enough times that I want to stop and ask what that word means. The only definition I was able to find via googling was [Julia's](http://juliacon.org/2018/talks_workshops/64/): > [@](#): > > **Federated package ecosystem.** This means that multiple independent parties can maintain both public and private packages and registries of them, and that projects can depend on a mix of public and private packages from different registries. which sounds like exactly what we're going to get from cargo supporting alternative registries, so whatever @Soni means by "federated" must be more than just that. Right? ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 27, 2018, 6:28pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/30 "2018-10-27T18:28:09Z")
it means the ability to publish crates depending on [example.org](http://example.org)’s whatever on [crates.io](http://crates.io), and _having [crates.io](http://crates.io) fetch the crates from [example.org](http://example.org) and cache them in [crates.io](http://crates.io), and having cargo fetch [example.org](http://example.org)’s packages from [crates.io](http://crates.io)_, so it’s NOT what the “alternative registries” RFC proposes. the “alternative registries” RFC proposes: registries are independent and fully isolated, so they can’t ever talk to eachother. dependencies from different registries aren’t allowed to be mixed together. it’s completely different. both involve independent parties and independent moderation, but, for benefits of federation: (non-federation lacks these, so they can be considered drawbacks for non-federation) - reliability, as if a registry goes down you can just switch to another and everything’s cached - deduplication, rather than publishing (separately) on multiple registries, you only publish once and it gets automatically distributed - namespacing (as talked about in this post) - there are more I can’t currently think of, but I encourage ppl to talk about them as well (: otoh, federation has the following drawbacks compared to non-federation: - wider attack surface, as you can hack another registry and the hacked contents will get automatically distributed as with a non-malicious crate. (malware scans help mitigate this problem - remember: always sanitize your inputs, even if they come from a federated server ;)) - um, there are probably more that I can’t think of? (“change of domain ownership” etc aren’t a problem if the server signature (public key) also changes, so I’m not sure if it should be counted here. but do note that the signature is independent of the domain name!) ---
**Author:** ![ethanpailes](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ethanpailes/32/4812_2.png) [@ethanpailes](https://internals.rust-lang.org/u/ethanpailes)\ **Post date:** [October 28, 2018, 5:56pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/32 "2018-10-28T17:56:00Z")
I haven't used the JVM ecosystem extensively, so perhaps I was wrong. I was under the impression that the `groupId` would show up in `import` statements in your code as well as any place where you use the fully qualified name in an expression. For example, I see some spring tutorials that contain the line `import org.springframework.web.bind.annotation.RequestMapping;`. Isn't `org.springframework` from the groupId of the package? > Fortunately, Rust doesn’t even have the rather arbitrary (and unenforced) package naming convention and I’m not suggesting that Rust should adopt it. (That design smells a bit like the stuff suggested in [[Pre-RFC]: Packages as Namespaces](https://internals.rust-lang.org/t/pre-rfc-packages-as-namespaces/8628/32) though, which I think is a poor idea for the obvious reasons.) Could you expand on that a bit? I'm not sure what you mean by "arbitrary (and unenforced) package naming convention". Is it a java naming thing? Also, if you have objections to packages as namespaces besides the ability to name crates of the same name in different namespaces, I would love it if you would share them over on that thread. ---
**Author:** ![Uther](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/uther/32/6225_2.png) [@Uther](https://internals.rust-lang.org/u/Uther)\ **Post date:** [October 28, 2018, 9:04pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/33 "2018-10-28T21:04:13Z")
Using reverse url to name packages in Java is just an old convention (since java 1.0 IIRC, long before any package manager), but it is not mandatory at all. ---
**Author:** ![ethanpailes](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ethanpailes/32/4812_2.png) [@ethanpailes](https://internals.rust-lang.org/u/ethanpailes)\ **Post date:** [October 28, 2018, 9:07pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/34 "2018-10-28T21:07:55Z")
Ah, thanks! ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [October 29, 2018, 2:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/36 "2018-10-29T14:34:44Z")
Where do existing packages where `package.name` and `lib.name` don’t match fit into this? I think a more interesting end goal is embracing the separation between `package.name` and `lib.name`, and effectively having _everyone_ use rename-dependencies (by convention instead of requirement): ```rust [dependencies] serde = { version = "1.0", org = "serde.rs", package = "serde" } ``` This way it doesn’t matter what `lib.name` is, just the name of the package (and organization). ---
**Author:** ![ethanpailes](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ethanpailes/32/4812_2.png) [@ethanpailes](https://internals.rust-lang.org/u/ethanpailes)\ **Post date:** [October 29, 2018, 9:38pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/37 "2018-10-29T21:38:55Z")
That makes sense. It seems like a pretty reasonable way to approach things. ---
**Author:** ![liigo](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/liigo/32/454_2.png) [@liigo](https://internals.rust-lang.org/u/liigo)\ **Post date:** [October 30, 2018, 12:02am UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/38 "2018-10-30T00:02:50Z")
If crate name is still unique through out of [crate.io](http://crate.io), people still need squatting crate name. Why you claim namespace addresses the squatting issue? ---
**Author:** ![taralx](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/taralx/32/3026_2.png) [@taralx](https://internals.rust-lang.org/u/taralx)\ **Post date:** [October 30, 2018, 8:41am UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/40 "2018-10-30T08:41:33Z")
I’m very supportive of this. I come from Go, where it is very normal to have domain names in the source code directly. No, it doesn’t matierially make it harder to switch from one package to another – either they implement the same API (and it’s a search & replace operation) or they don’t (and it’s a bigger task anyway). It irks me to no end how misleading the `crates.io` namespace is – I’ve found myself using bad, unmaintained, and suboptimal crates on a regular basis because it looks like a curated namespace but isn’t. At least with domains we make it clear that you’re just picking up some person’s idea of the thing. ---
**Author:** ![anon2808951](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@anon2808951](https://internals.rust-lang.org/u/anon2808951)\ **Post date:** [October 30, 2018, 2:06pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/41 "2018-10-30T14:06:48Z")
(post deleted by author) ---
**Author:** ![liigo](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/liigo/32/454_2.png) [@liigo](https://internals.rust-lang.org/u/liigo)\ **Post date:** [October 30, 2018, 2:50pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/42 "2018-10-30T14:50:28Z")
You said, keep everything that exists as it is, add `organization`. Crate name is unique now, which you don’t change. ---
**Author:** ![OZ\_](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/oz_/32/4298_2.png) [@OZ\_](https://internals.rust-lang.org/u/OZ_)\ **Post date:** [October 30, 2018, 4:30pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/43 "2018-10-30T16:30:07Z")
> [@taralx](#): > > where it is very normal to have domain names in the source code Do you need to verify your domain? * * * I'm pretty sure that this idea, if adopted, will also add a lot of lines to config.toml file. Maybe for Java world it's ok to have huge xml configs, but I don't want this destiny for Rust. ---
**Author:** ![taralx](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/taralx/32/3026_2.png) [@taralx](https://internals.rust-lang.org/u/taralx)\ **Post date:** [October 30, 2018, 8:20pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/44 "2018-10-30T20:20:32Z")
> [@OZ\_](#): > > Do you need to verify your domain? No, because either you're hosting a package there or you're not. There's no arbiter that you have to prove things to. ---
**Author:** ![mbrubeck](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mbrubeck/32/174_2.png) [@mbrubeck](https://internals.rust-lang.org/u/mbrubeck)\ **Post date:** [October 31, 2018, 1:50pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/50 "2018-10-31T13:50:36Z")
[Everyone, please try to raise the level of discussion here. Focus on adding new information or ideas, and asking questions about things you need clarified. Flag inappropriate or unconstructive comments rather than replying to them.] ---
**Author:** ![Cazadorro](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cazadorro/32/4551_2.png) [@Cazadorro](https://internals.rust-lang.org/u/Cazadorro)\ **Post date:** [October 31, 2018, 3:00pm UTC](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688/52 "2018-10-31T15:00:35Z")
@anon2808951 I’m confused, Looking up top it seems there was a lot of good discussion on the downsides of this, but I’m not sure if this has been addressed and how? This post has gotten very long with side conversations not relevant to continuing discussion for “Domains as namespaces” How do we solve the “I need to own a domain first” or “I no longer care about maintaining the domain” or “my domain was hacked” or “some one else owns my domain now” as well as anything else that was mentioned. Is there a way for you to collect the relevant arguments made in this thread and your arguments against them? Maybe post an edit to the original post and create a new post down here so people can focus on taking on the challenges of this approach? [Previous page](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688.md?page=1) [Next page](https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688.md?page=3)