15 ms·

The lack of namespaces on crates.io is a feature

108 points by LinuxBender 6y ago

wildchild 6y ago
true. like in php.
cornstalks 6y ago
For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language. Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number of situations where a crate will have subcrates. Sometimes these subcrates are intended to be used publicly (e.g., you want people to be able to use just the "foo_bar" subcrate if they don't need the whole "foo" crate) Sometimes these subcrates aren't intended to be used publicly (e.g., Cargo forces you to put your proc macro in a separate crate, but that's an implementation detail of "foo" and isn't something other people should use directly). So now you have "foo" on crates.io, as well as a bunch of "foo_*" subcrates on crates.io. Currently there is nothing stopping some random developer from publishing their own "foo_haha" crate. This new crate isn't related to your "foo" crates and might even be squatting on a name you would have liked to use for a subcrate. Or multiple people might want to create different crates for similar things. e.g., there are multiple regular expression crates. But only one of these crates got the "regex" name. Everyone else has to use a different name, and sometimes people use creative (unintuitive) crate names. So for various reasons, some people want namespacing on crates.io that would allow someone to reserve an entire namespace. This would allow you to prevent others from using a name that might be confusingly similar to yours. It also allows you to use conflicting crate names if multiple people want to publish different crates with the same name. TL;DR some people want something like npm's scopes for crates.io. And other people don't want it. This has led to much debate and arguing and whatnot. It's funny, though, because the team that owns crates.io almost never weighs in on the discussion, and on the rare occasion that one of the team members does say something they always do it in a personal capacity and not in a way that represents the team. This has created its own set of frustrations.
- AuthorizedCust 6y ago
  The article's title is poor. "namespaces in [language name]" should be about the traditional computer science notion of namespaces. A better title may be "No Namespaces in Rust's Package System Is a Feature", although that is long.
  - dang 6y ago
    We edited the title following kibwen's suggestion: https://news.ycombinator.com/item?id=24444812 https://news.ycombinator.com/item?id=24444812
- steveklabnik 6y ago
  > the team that owns crates.io almost never weighs in on the discussion There's two big things here: 1. "The discussion" has often happened outside of the contexts that the teams are supposed to evaluate; that is, RFCs are the way in which policies are changed, and the vast majority of the discussions here haven't been on RFCs, but on forum threads. Team members cannot be everywhere, and comments outside of the decision making process are kinda inherently non-normative. 2. Team members used to comment more in these threads but they've gone back and forth and around and around for years, and people are frustrated by it, so they've just stopped commenting in these threads. See #1. When it's optional, and it isn't pleasant, it shouldn't be a surprise that people don't participate. (I am not on the relevant team anymore, to be clear.)
  - krainboltgreene 6y ago
    I mean while I absolutely understand the latter situation, the former doesn't feel as understandable because the team could just...make an rfc for it. If you community is clamoring about something, but no one has stepped up to make an RFC for the situation, you have to do two things: 1. Make an RFC for the clamor 2. Figure out why no one has done this already As you know, the lack of response is as much a response as any response.
    - steveklabnik 6y ago
gw 6y ago
You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? Most now seem to agree it wasn't a good idea. When the "collapsed" name falls out of maintenance, the forks will all seem somehow less "official", even if they are much higher quality. Forks are inevitable; why would you want to discourage them? I finally decided to start using the reverse of my personal domain for my future libraries. The java folks were right all along.
- dllthomas 6y ago
  > Forks are inevitable; why would you want to discourage them? The conclusion that we don't want to discourage forks may be valid, but this doesn't seem to be good reasoning. Lots of things are inevitable that we want to discourage or delay.
- setr 6y ago
  >Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, maintaining that source of truth is otherwise known as centralization, with all the problems that brings, but there's nothing inherently wrong with forking.. that's just the natural specialization and evolutionary processes at work. The solution is to make it easier to find those top-tier libraries, and this is orthogonal to forking; mainly handled by blog posts and "official" library listings/recommendations, and things like This Week in Rust.... namespacing or not doesn't really get you anything there.
  - PuercoPop 6y ago
papaf 6y ago
I remember when this came up because of the following user: https://crates.io/users/swmon https://crates.io/users/swmon
- renewiltord 6y ago
  Interestingly, you can't name squat on GitHub. I just asked them for the guy squatting my first name and they gave it to me. Ah, the power of non-community-run product. You can do the right thing without having to worry about the slippery slope.
  - kbenson 6y ago
    > I just asked them for the guy squatting my first name and they gave it to me. Your... first name? So "rene" (if I was to assume a few things about your username)?
    - renewiltord 6y ago
      Haha, that's not my real first name. You know, like how Ronaldinho's actual first name is Ronaldo? Like that. The actual name.
      - kbenson 6y ago
        Sure, and that's why I said I was assuming, but my (poorly communicated) intent was to question how unique your first name is, and how someone is squatting on it if it's a real account and maybe they have that name too? I mean, it's probably not a big deal in this case. But if I had a github account that someone wanted and github just gave out my (personal?) info, I might feel a bit betrayed by them. I know, I shouldn't give them any info I really want private, but that doesn't mean I can't expect them to act responsibly with what I have given them. I just didn't want to state all that up front, because it assumes a lot about what happened when there wasn't a lot of detail provided. It is nice when people can just make simple stuff happen though, I agree. It's just a hard line to walk, because you allow that and then you get stuff like the recent Twitter hack. It's hard for us to all have nice things and nice people that can help us because there really are a bunch of people out there to get you (or someone in a similar situation, at least). :/
andrewzah 6y ago
The lack of namespaces in the crates registry (combined with allowing squatting) is easily one of the worse aspects of Rust.
- kzrdude 6y ago
  Please elaborate, why?
  - andrewzah 6y ago
    Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine. The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result. But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-? I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc. Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.
    - kibwen 6y ago
      > why namespaces are just -impossible- As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatype). Solve the funding issue first, and then you can start solving the rest.
      - 6y ago
richardwhiuk 6y ago
It's not clear why any of the advantages they tout occur because of the lack of namespaces.
hinkley 6y ago
We really need a colorful term for the practice of ‘splaining to people how a frustrating part of your code is not only not a bug but you are either doing it (to them) on purpose, or pretending to have done so in order to save face. Bugsplaining?
- aidenn0 6y ago
  "It's not a bug it's a feature" is the phrase I usually see thrown about for things like this.
  - hinkley 6y ago
    That's the 'gold standard' but it leaves it open to interpretation. Some people mean it with very little sense of irony. Do you think Sam is being ironic with that title, or sincere? His intro is telling us how he's going to calmly explain to us dumb hicks and newbies that we wouldn't know a feature if it bit us on the ass (which it most definitely will, at some point). The rest of the article doesn't (quite) follow up on that warning, but if you start out by putting everyone on guard nobody is going to listen to you.
    - ChrisSD 6y ago
      The intro says that Sam is laying out the advantages of no-namespacing because typically only the disadvantages are discussed. Sam also makes clear that they're "summarizing points raised across the various proposals I’ve read". The rest of the article follows through on the intro's promise.
- andrewzah 6y ago
  Buglighting. (Bug + gaslighting). "You don't actually have that problem. The system doing that is expressly a feature for you."
  - hinkley 6y ago
    Hmmm. I admit yours is easier to create an icon for. Not sure about recognition, or the vaguely defined requirement to avoid Poe's Law.
lucideer 6y ago
> This is a strike against any namespace system that allows namespace ownership to unexpectedly change. Discontinuous identity has a couple of issues. Hard agree but this has nothing to do with namespaces. This is equally applicable to names in a flat registry. I don't see the point of bringing this up in this article. > there are also real benefits. [...] discourages forks What. How? Why? I guess there's possibly some valid argument for disliking forks (though it's certainly not put forward in this article), but discouraging them via package registry structure is... delusional. Forks are a reality of software and they neither happen as a result of registry structures, nor can the be discouraged by their designs. They happen for entirely external, human reasons, and a well-designed registry structure (i.e. a non-flat one) will be set up to be resilient to forking.
- zokier 6y ago
  The whole "Continuity" section seems completely red herring and orthogonal to the namespace issue.
- Supermancho 6y ago
  Aspects of Registry Structure - Identity Continuity Stability Squatting None of these are features, which are incompatible with namespaces. I can't find a compelling reason that Crate works this way in this entire article. The article reads like a list of "why Crate is poorly implemented". Of course, it works when the community is rather young and small. Give it time.
kibwen 6y ago
This article is poorly titled; it's about the lack of namespaces on crates.io. Rust does have namespaces. Cargo is capable of supporting registries that use namespaces. Using Rust doesn't even require one to use Cargo, and using Cargo doesn't require one to use crates.io. (For the record, I do think that namespaces on crates.io would be a marginal improvement, but the benefits are often overstated and it would add organizational costs that the crates.io maintainers can't currently bear. The amount of ire over this topic is disproportionate to its impact.)
- dang 6y ago
  Ok, we'll use your phrasing above. Thanks!
013a 6y ago
If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces." The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change. But, this is the nature of open source (and even startups). New projects start under the (oftentimes correct) belief that they can do something better, which experiences linear extrapolation into believing everything you do is better through virtue of being unlike what everyone else is doing. We see the end-state of Maven, NPM, etc; we don't see the war that those projects went through to reach this state. History is elided, forgotten, then repeated.
- steveklabnik 6y ago
  > The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change. Comments like this are why this discussion has devolved over the years. It's "all heat and no light." It does not help convince anyone that you're right, and if you want this to change, I would suggest that you change your approach. The team has stated that they are open to implementing namespaces, but that the people who advocate for them need to address the concerns. This hasn't been done successfully yet, and is part of what this post is trying to help out with, by cataloging some of the large amounts of previous discussion.
  - voxl 6y ago
    What concerns? Most people don't care because they feel that the ship has sailed, the mistake is set in the concrete. Transitioning thus becomes the biggest conceivable concern for me. What are the other possible concerns? The only comments I've seen on this is "It's not any different, people will just squat namespaces" to which I reply: reserve namespaces up front for Rust nursery and bespoke crates. That has always been the biggest benefit of namespaces, when i type "std.rand" I never have to worry about an attacker squatting "std.rnd". But I could just mistype the namespace! Fine, I could, but all the obvious mistypings could _also_ be reserved!
renewiltord 6y ago
How does crates.io treat bad faith stuff? Like if someone were to make com-steveklabnik-blog.
- steveklabnik 6y ago
  "bad faith stuff" is not dealt with directly. You could absolutely publish that crate right now, and I would have no inherent recourse about it. For the most part, unless a lawyer says that it needs to be taken down, things aren't taken down. There is a small amount of wiggle room around registering a large number of packages in an automated fashion, but generally speaking, the principle is non-intervention.
  - renewiltord 6y ago
    Cool. I guess there's no real reason to solve a problem till it's a problem. Hasn't hurt me yet so optimizing for adoption doesn't seem so bad.
  - dastbe 6y ago
    What qualifies as "a large number of packages"? As was posted in another thread, it seems like the packages of user https://crates.io/users/swmon https://crates.io/users/swmon would qualify? Alternative to just removing them, would the crates team be more open to transferring ownership of these packages?
    - steveklabnik 6y ago
      The focus in that sentence is not "a large number of packages," but the "in an automated fashion." Plus, that's only 100 packages. There are people who legitimately maintain more crates than that. > would the crates team be more open to transferring ownership of these packages? https://github.com/rust-lang/rfcs/pull/2614 https://github.com/rust-lang/rfcs/pull/2614
      - dastbe 6y ago
        Yeah, it's not obvious what the person I linked's intent is. Resale? I'm pessimistic that the above mechanism would work but I'm glad that rust is thinking about it. fwiw I also don't think namespacing necessarily solves this problem, it just shoves the squatting problem up a level.
wilsocr88 6y ago
This makes me think of how Python coders say that code is or isn't "Pythonic" So what would Rusts equivalent be... Rustic? Namespaces are not Rustic.
- ifmpx 6y ago
  > Namespaces are not Rustic why do you think that?
zelly 6y ago
I'm sorry but a language that has data entropy and link rot built into its compiler is not appealing to me. I prefer the Go approach which lets you host or import packages via a HTTP or git URI. If you have to have packaging built-in to the standard toolchain these days, then please use already well-known and existing protocols like DNS and git. Java also figured this out years ago (com.sun... etc).
- steveklabnik 6y ago
  To be clear, you can always depend on a package from your own host, or from a git URL, today.
  - Arnavion 6y ago
    You can also make an alternative registry and add dependencies from that registry. That said, an alternative registry that enforces namespacing would not work, just because of cargo's limitations on package names that prevent characters like / It could be done by making every "namespace" a different registry, and for those registries to allow packages with dependencies from other registries (something that crates.io doesn't allow, for a reasonably good reason). Would be quite verbose for the user though.
- zokier 6y ago
  crates.io is package repository, cargo is a build tool, rustc is the compiler, and they all three are separate entities. rustc as far as I know operates solely on local files, and has no built-in logic or knowledge about crates.io. And cargo can be configured to use different repository than crates.io, which can have different naming policy
ithkuil 6y ago
This is why I like the Go approach: just use an existing global namespacing system and delegate to it all ownership disputes etc: DNS + actual web servers serving traffic (not necessarily just got repos, since the "vanity imports" offer an indirection based in html meta tags)
- steveklabnik 6y ago
  Yes, there are benefits to that approach. We rejected it because we want builds to be reproducible, and not to have that property depend on external entities.
  - ithkuil 6y ago
    That's orthogonal with the naming scheme. In fact the Go team eventually implemented a way to decouple the storage of a copy of the package from the name of the package, namely the goproxy. How they got there was admittedly a bit clumsy, but it proves that it's possible
    - steveklabnik 6y ago
      Sort of; you can still delete github repos and the proxy doesn't keep a copy forever, right?
      - ithkuil 6y ago
        That's an implementarion choice of the proxy. You can run a private proxy that inplementa whatever policy you want. If crates wants a policy that stores crates forever then just store crates forever. What I'm talking about just affects how new crates and new versions of existing crates get "uploaded". Imagine you call your crate foo.com/bar. In order to push your crate the crates server needs to verify that you actually own the foo.com/bar URL. There are many ways to do that. A simple one is to just have the crates server pull code from that URL instead of pushing it. If you want to push (e.g. to work around reachability issues such as firewalls) it's just the matter of devising one or more ways to prove that you "own" that handle. For example by serving some challenge response in a html meta tag
didibus 6y ago
I hate namespaces like everyone else, because they're inelegant and kind of uncool. dependencies: regex Vs dependencies: com.cooladtech/regex But the world doesn't let us have it elegantly, because the library with the name "regex" will almost never be the regex library you want to use. It will almost never happen to be the best, most maintained, best documented, highest performing, with all the regex features you need library. So instead, the regex library you want will be called "potato". Like a hot potato, potato doesn't let you down when parsing regex. And then there's the issue of groups of packages that generally make sense together, and no good way to define those groups. So you might have: regex_core regex_engine and regex_api, but it turns out regex_api is for another package and not really part of the group. Anyhow, back to the article... Identity? So I read and re-read the section on identity, and I'm not sure what they're saying, it seems they're saying that not having namespaces makes identity worse for discoverability? So basically it argues for namespaces? Now I'm confused... > A flat registry makes identity management (naming a crate) harder Than for continuity, it seems to say that if you have a namespace it's bad, because you could confuse two packages of the same name, but in different namespaces? Okay, I did see this sometimes, mostly in tutorials where they don't list their dependencies, but only their import statements (and sometimes they don't even list the imports). So the reader is kind of left figuring which "regex" lib they are supposed to choose since it exists in many places. But then the post also says that the lib name can differ from the package.name already? Which means you can already have the same lib name for two different packages in Crates? So I'm confused again? > Updating to a new package version with different content under different ownership is a real security risk I have no idea how this would happen unless I manually changed the dependency to point to the one from somewhere else? So I really don't get the risk here. > Doubly so if you don’t ban new minor versions on the last major version after an unintentional ownership change Okay, hold on a second. I don't think this article is debating what I think having namespaces mean. Here it seems like the article imagined a world where you depend on the package name and do not specify a namespace, and then in crates.io someone could transfer the ownership of the package to someone else. Or something like that? This makes zero sense to me, I need someone to explain it to me. > This is a strike against schemes that encourage multiple distinct crates to have the same default name in code. I don’t think any proposal that encourages this could be approved. Okay, now we're talking. This is a GREAT point. Obviously, the import statement must include the namespace as well. Otherwise you can depend on two packages and have import conflicts where who knows which module you're getting? But is this about namespaces? Maybe the argument here is that the way Rust work, this would not be the case, thus risky? If true, I think this is a defeating argument honestly, something has to be done about this. Also it sounds like this is already a problem, because lib name can differ from package name? Anyhow, I'd direct people to this amazing post from the Go world, and I think they got everything right when it comes to their view of package management: https://research.swtch.com/vgo-principles https://research.swtch.com/vgo-principles
hevelvarik 6y ago
I don’t know Rust but have learned enough about it to know that lack of namespaces in crates.io and anything at all Rust related Is inarguably a feature
hombre_fatal 6y ago
It's actually terrible, justs look at NPM and RubyGems. Instead of just coming up with a good name for your project, you have to come up with a unique one even though the project with that name isn't even active. And since most names are taken, you have to come up with a clever one for no real reason. Or go down the route of naming strats you see on npm/gems: better-lib, lib2, lib2-better, lib3, better-lib3, etc. It really does nobody good except for the person who was able to clutch the original name, and that's a weird incentive structure. Subreddits have this same problem where you're instantly gimped when named anything other than r/bitcoin, r/politics, r/news, r/atlanta, etc. Instead, there should be no preciousness to names nor dictionary words. That's the correct incentive structure: none. People keep linking https://crates.io/users/swmon https://crates.io/users/swmon and it probably seems like an easy fix to just revoke those names. But swmon isn't the problem, the system is. It's no bigger problem when swmon does it overtly vs thousands of people doing it incidentally when they register a package they don't do anything with. The problem isn't to calibrate a system that can detect swmon but build a system where you don't care what swmon does. What you want is something like this: https://package.elm-lang.org/ https://package.elm-lang.org/ Watching Crates get this wrong was like watching Swift not implement qualified imports.
tikhonj 6y ago
> So what’s a bad actor? I consider someone who squats a bunch of crates to make or point or prevent their names from being used to be a bad actor. In my experience, the thorny problem with namespaces isn't bad actors because you can fix that with content moderation. Yes, that takes time and effort which can be scarce in an open-source community, but it's doable. No, the thorny problem is good actors with bad execution: people who publish a package with a nice name that does what it says it does, more or less, but does it poorly. It doesn't cover all the edges case or it is poorly optimized or it has limited features or it has some fatal design flaw in its architecture... Maybe it was fine at some point but just hasn't kept up with the times. So what do you do if a package like that grabs the name "json" or "http" or something? You don't want to kick packages off just for not being great, but you also don't want it to seem like the de facto package for a task in your language. I do a lot of Haskell, and it's not the best developer experience when you have to tell people "don't use json, use aeson instead". Namespaces would solve this problem. You could have a "blessed" namespace (like rust/) and, when functionality becomes important enough that the quality of the "default" package matters use the namespace to provide that package (rust/json, rust/http... etc). You don't have to kick off the existing package (even if it's squatting a "nice" namespace like json/json) but you also don't get into the point where packages with nice names look fine but are actually flawed and a bad choice for real work.
solatic 6y ago
If anything, namespacing doesn't go far enough. We have a wonderful namespacing mechanism already for the Internet - it's called DNS. We use DNS validation as a security foundation for issuing TLS certificates. Package registries should allow me to "own a domain" - backed up by DNS validation - and upload packages under that name. "Domain ownership" should be paired to a timestamp issued at verification time, so that a) package uploading can be blocked entirely if the DNS verification is lost, b) consumers can continue to download packages under the old domain timestamp c) domain ownership can still transfer as needed d) changes in ownership are tracked, and consumers are notified. Why does everybody always have to reinvent the wheel? DNS has been around for decades. Using DNS records to verify ownership has been around since, what, the early days of the ACME protocol in 2014/2015? Earlier?
- steveklabnik 6y ago
  DNS records have a financial and technical barrier to account and package creation that we found unacceptable; and those costs are ongoing, leading to an unacceptable level of mutability.
  - solatic 6y ago
    Well, you don't have to only accept DNS records! It's like arguing that independent email providers shouldn't provide general addresses like @gmail.com or @fastmail.com if they're going to provide any support for custom domains. You could do both. In fact, offering support for custom domains is usually an opportunity to up-sell, particularly to the kind of customers who have already shown that they're willing to spend money on an on-going basis (by paying for the DNS name).
    - steveklabnik 6y ago
      I’m still not sure how that solves the problem, but regardless, the point is that there are many possibilities and tons of complexity. It is not a simple, unambiguous problem with a clear correct answer.
gbear0 6y ago
It sounds like both flat hierarchies and namespaces won't work cause both sides have fundamental problems that can't be solved in a way that everyone agrees upon. So what about combining them and having the best of both worlds? I think the docker namespace schema provides a great way to have a 2 stage lookup where the first part of the id (up until the last '/') is a full url to the registry, and the last name in the id is the flat hierachy of names for that registry. In fact this scheme is already supported with cargo since you can specify the registry per dep. This means the default registry, if nothing is added is 'crates.io/' but you can specify any other registry, eg 'gitlab.local/looks/like/namespace' for personal CI, or even 'crates.io/{username}' Let's give each user their own registry at 'crates.io/{username}'. This works in a backwards compatible way cause registry:'crates.io/' + crate:'mypackage' is different than registry:'crates.io/mypackage' + crate:'mypackage', so nothing changes with the current crates and it's all an incremental implementation detail for crates.io Now we have the npm user style namespace ids that lessens the namesquatting problem, but increases the security issues if the registry changes hands. Honestly, I've never really understood the security argument here cause there's no reason an owner can't hand over a single package. As well, there's no reason a currently trusted owner can't patch update a package with bad code. This is a social problem that has no solution and is the same for both naming systems, so we need to come up with another way of handling things. Personally I think all published crates should be immutable and all deps should be pegged, not even allowing patches. But this leads to the argument that sometimes publishers really do want to take down a crate. I'm on the fence with this one, so let's try to solve it in another way. So the problem is we need to potentially remap any (transitive) dependency to something else, and since we still have a flat hierarchy we really just need to remap the registry for that dependency. So let's add a registry remapping section for the cargo deps ... wait cargo already has something for that (https://doc.rust-lang.org/cargo/reference/source-replacement.html https://doc.rust-lang.org/cargo/reference/source-replacement...). (Reading through the docs here, it does seems like it might be a little strict on whether we can use it for this case, but it's pretty close.) OK wrapping up, it looks like we could have backwards compatible namespaces right now if crates.io would just implement user specific registries, ie it's an implementation detail. And the security issues are really no different than before. Thus I've got to ask, what am I missing?

108 points by LinuxBender 6y ago

true. like in php.

For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language. Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number of situations where a crate will have subcrates. Sometimes these subcrates are intended to be used publicly (e.g., you want people to be able to use just the "foo_bar" subcrate if they don't need the whole "foo" crate) Sometimes these subcrates aren't intended to be used publicly (e.g., Cargo forces you to put your proc macro in a separate crate, but that's an implementation detail of "foo" and isn't something other people should use directly). So now you have "foo" on crates.io, as well as a bunch of "foo_*" subcrates on crates.io. Currently there is nothing stopping some random developer from publishing their own "foo_haha" crate. This new crate isn't related to your "foo" crates and might even be squatting on a name you would have liked to use for a subcrate. Or multiple people might want to create different crates for similar things. e.g., there are multiple regular expression crates. But only one of these crates got the "regex" name. Everyone else has to use a different name, and sometimes people use creative (unintuitive) crate names. So for various reasons, some people want namespacing on crates.io that would allow someone to reserve an entire namespace. This would allow you to prevent others from using a name that might be confusingly similar to yours. It also allows you to use conflicting crate names if multiple people want to publish different crates with the same name. TL;DR some people want something like npm's scopes for crates.io. And other people don't want it. This has led to much debate and arguing and whatnot. It's funny, though, because the team that owns crates.io almost never weighs in on the discussion, and on the rare occasion that one of the team members does say something they always do it in a personal capacity and not in a way that represents the team. This has created its own set of frustrations.

AuthorizedCust 6y ago
The article's title is poor. "namespaces in [language name]" should be about the traditional computer science notion of namespaces. A better title may be "No Namespaces in Rust's Package System Is a Feature", although that is long.
- dang 6y ago
  We edited the title following kibwen's suggestion: https://news.ycombinator.com/item?id=24444812 https://news.ycombinator.com/item?id=24444812
steveklabnik 6y ago
> the team that owns crates.io almost never weighs in on the discussion There's two big things here: 1. "The discussion" has often happened outside of the contexts that the teams are supposed to evaluate; that is, RFCs are the way in which policies are changed, and the vast majority of the discussions here haven't been on RFCs, but on forum threads. Team members cannot be everywhere, and comments outside of the decision making process are kinda inherently non-normative. 2. Team members used to comment more in these threads but they've gone back and forth and around and around for years, and people are frustrated by it, so they've just stopped commenting in these threads. See #1. When it's optional, and it isn't pleasant, it shouldn't be a surprise that people don't participate. (I am not on the relevant team anymore, to be clear.)
- krainboltgreene 6y ago
  I mean while I absolutely understand the latter situation, the former doesn't feel as understandable because the team could just...make an rfc for it. If you community is clamoring about something, but no one has stepped up to make an RFC for the situation, you have to do two things: 1. Make an RFC for the clamor 2. Figure out why no one has done this already As you know, the lack of response is as much a response as any response.
  - steveklabnik 6y ago

gw 6y ago

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? Most now seem to agree it wasn't a good idea. When the "collapsed" name falls out of maintenance, the forks will all seem somehow less "official", even if they are much higher quality. Forks are inevitable; why would you want to discourage them? I finally decided to start using the reverse of my personal domain for my future libraries. The java folks were right all along.

dllthomas 6y ago
> Forks are inevitable; why would you want to discourage them? The conclusion that we don't want to discourage forks may be valid, but this doesn't seem to be good reasoning. Lots of things are inevitable that we want to discourage or delay.
setr 6y ago
>Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, maintaining that source of truth is otherwise known as centralization, with all the problems that brings, but there's nothing inherently wrong with forking.. that's just the natural specialization and evolutionary processes at work. The solution is to make it easier to find those top-tier libraries, and this is orthogonal to forking; mainly handled by blog posts and "official" library listings/recommendations, and things like This Week in Rust.... namespacing or not doesn't really get you anything there.
- PuercoPop 6y ago

papaf 6y ago

I remember when this came up because of the following user: https://crates.io/users/swmon https://crates.io/users/swmon

renewiltord 6y ago
Interestingly, you can't name squat on GitHub. I just asked them for the guy squatting my first name and they gave it to me. Ah, the power of non-community-run product. You can do the right thing without having to worry about the slippery slope.
- kbenson 6y ago
  > I just asked them for the guy squatting my first name and they gave it to me. Your... first name? So "rene" (if I was to assume a few things about your username)?
  - renewiltord 6y ago
    Haha, that's not my real first name. You know, like how Ronaldinho's actual first name is Ronaldo? Like that. The actual name.
    - kbenson 6y ago
      Sure, and that's why I said I was assuming, but my (poorly communicated) intent was to question how unique your first name is, and how someone is squatting on it if it's a real account and maybe they have that name too? I mean, it's probably not a big deal in this case. But if I had a github account that someone wanted and github just gave out my (personal?) info, I might feel a bit betrayed by them. I know, I shouldn't give them any info I really want private, but that doesn't mean I can't expect them to act responsibly with what I have given them. I just didn't want to state all that up front, because it assumes a lot about what happened when there wasn't a lot of detail provided. It is nice when people can just make simple stuff happen though, I agree. It's just a hard line to walk, because you allow that and then you get stuff like the recent Twitter hack. It's hard for us to all have nice things and nice people that can help us because there really are a bunch of people out there to get you (or someone in a similar situation, at least). :/

andrewzah 6y ago

The lack of namespaces in the crates registry (combined with allowing squatting) is easily one of the worse aspects of Rust.

kzrdude 6y ago
Please elaborate, why?
- andrewzah 6y ago
  Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine. The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result. But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-? I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc. Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.
  - kibwen 6y ago
    > why namespaces are just -impossible- As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatype). Solve the funding issue first, and then you can start solving the rest.
    - 6y ago

richardwhiuk 6y ago

It's not clear why any of the advantages they tout occur because of the lack of namespaces.

hinkley 6y ago

We really need a colorful term for the practice of ‘splaining to people how a frustrating part of your code is not only not a bug but you are either doing it (to them) on purpose, or pretending to have done so in order to save face. Bugsplaining?

aidenn0 6y ago
"It's not a bug it's a feature" is the phrase I usually see thrown about for things like this.
- hinkley 6y ago
  That's the 'gold standard' but it leaves it open to interpretation. Some people mean it with very little sense of irony. Do you think Sam is being ironic with that title, or sincere? His intro is telling us how he's going to calmly explain to us dumb hicks and newbies that we wouldn't know a feature if it bit us on the ass (which it most definitely will, at some point). The rest of the article doesn't (quite) follow up on that warning, but if you start out by putting everyone on guard nobody is going to listen to you.
  - ChrisSD 6y ago
    The intro says that Sam is laying out the advantages of no-namespacing because typically only the disadvantages are discussed. Sam also makes clear that they're "summarizing points raised across the various proposals I’ve read". The rest of the article follows through on the intro's promise.
andrewzah 6y ago
Buglighting. (Bug + gaslighting). "You don't actually have that problem. The system doing that is expressly a feature for you."
- hinkley 6y ago
  Hmmm. I admit yours is easier to create an icon for. Not sure about recognition, or the vaguely defined requirement to avoid Poe's Law.

lucideer 6y ago

> This is a strike against any namespace system that allows namespace ownership to unexpectedly change. Discontinuous identity has a couple of issues. Hard agree but this has nothing to do with namespaces. This is equally applicable to names in a flat registry. I don't see the point of bringing this up in this article. > there are also real benefits. [...] discourages forks What. How? Why? I guess there's possibly some valid argument for disliking forks (though it's certainly not put forward in this article), but discouraging them via package registry structure is... delusional. Forks are a reality of software and they neither happen as a result of registry structures, nor can the be discouraged by their designs. They happen for entirely external, human reasons, and a well-designed registry structure (i.e. a non-flat one) will be set up to be resilient to forking.

zokier 6y ago
The whole "Continuity" section seems completely red herring and orthogonal to the namespace issue.
Supermancho 6y ago
Aspects of Registry Structure - Identity Continuity Stability Squatting None of these are features, which are incompatible with namespaces. I can't find a compelling reason that Crate works this way in this entire article. The article reads like a list of "why Crate is poorly implemented". Of course, it works when the community is rather young and small. Give it time.

kibwen 6y ago

This article is poorly titled; it's about the lack of namespaces on crates.io. Rust does have namespaces. Cargo is capable of supporting registries that use namespaces. Using Rust doesn't even require one to use Cargo, and using Cargo doesn't require one to use crates.io. (For the record, I do think that namespaces on crates.io would be a marginal improvement, but the benefits are often overstated and it would add organizational costs that the crates.io maintainers can't currently bear. The amount of ire over this topic is disproportionate to its impact.)

dang 6y ago
Ok, we'll use your phrasing above. Thanks!

013a 6y ago

If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces." The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change. But, this is the nature of open source (and even startups). New projects start under the (oftentimes correct) belief that they can do something better, which experiences linear extrapolation into believing everything you do is better through virtue of being unlike what everyone else is doing. We see the end-state of Maven, NPM, etc; we don't see the war that those projects went through to reach this state. History is elided, forgotten, then repeated.

steveklabnik 6y ago
> The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change. Comments like this are why this discussion has devolved over the years. It's "all heat and no light." It does not help convince anyone that you're right, and if you want this to change, I would suggest that you change your approach. The team has stated that they are open to implementing namespaces, but that the people who advocate for them need to address the concerns. This hasn't been done successfully yet, and is part of what this post is trying to help out with, by cataloging some of the large amounts of previous discussion.
- voxl 6y ago
  What concerns? Most people don't care because they feel that the ship has sailed, the mistake is set in the concrete. Transitioning thus becomes the biggest conceivable concern for me. What are the other possible concerns? The only comments I've seen on this is "It's not any different, people will just squat namespaces" to which I reply: reserve namespaces up front for Rust nursery and bespoke crates. That has always been the biggest benefit of namespaces, when i type "std.rand" I never have to worry about an attacker squatting "std.rnd". But I could just mistype the namespace! Fine, I could, but all the obvious mistypings could _also_ be reserved!

renewiltord 6y ago

How does crates.io treat bad faith stuff? Like if someone were to make com-steveklabnik-blog.

steveklabnik 6y ago
"bad faith stuff" is not dealt with directly. You could absolutely publish that crate right now, and I would have no inherent recourse about it. For the most part, unless a lawyer says that it needs to be taken down, things aren't taken down. There is a small amount of wiggle room around registering a large number of packages in an automated fashion, but generally speaking, the principle is non-intervention.
- renewiltord 6y ago
  Cool. I guess there's no real reason to solve a problem till it's a problem. Hasn't hurt me yet so optimizing for adoption doesn't seem so bad.
- dastbe 6y ago
  What qualifies as "a large number of packages"? As was posted in another thread, it seems like the packages of user https://crates.io/users/swmon https://crates.io/users/swmon would qualify? Alternative to just removing them, would the crates team be more open to transferring ownership of these packages?
  - steveklabnik 6y ago
    The focus in that sentence is not "a large number of packages," but the "in an automated fashion." Plus, that's only 100 packages. There are people who legitimately maintain more crates than that. > would the crates team be more open to transferring ownership of these packages? https://github.com/rust-lang/rfcs/pull/2614 https://github.com/rust-lang/rfcs/pull/2614
    - dastbe 6y ago
      Yeah, it's not obvious what the person I linked's intent is. Resale? I'm pessimistic that the above mechanism would work but I'm glad that rust is thinking about it. fwiw I also don't think namespacing necessarily solves this problem, it just shoves the squatting problem up a level.

wilsocr88 6y ago

This makes me think of how Python coders say that code is or isn't "Pythonic" So what would Rusts equivalent be... Rustic? Namespaces are not Rustic.

ifmpx 6y ago
> Namespaces are not Rustic why do you think that?

zelly 6y ago

I'm sorry but a language that has data entropy and link rot built into its compiler is not appealing to me. I prefer the Go approach which lets you host or import packages via a HTTP or git URI. If you have to have packaging built-in to the standard toolchain these days, then please use already well-known and existing protocols like DNS and git. Java also figured this out years ago (com.sun... etc).

steveklabnik 6y ago
To be clear, you can always depend on a package from your own host, or from a git URL, today.
- Arnavion 6y ago
  You can also make an alternative registry and add dependencies from that registry. That said, an alternative registry that enforces namespacing would not work, just because of cargo's limitations on package names that prevent characters like / It could be done by making every "namespace" a different registry, and for those registries to allow packages with dependencies from other registries (something that crates.io doesn't allow, for a reasonably good reason). Would be quite verbose for the user though.
zokier 6y ago
crates.io is package repository, cargo is a build tool, rustc is the compiler, and they all three are separate entities. rustc as far as I know operates solely on local files, and has no built-in logic or knowledge about crates.io. And cargo can be configured to use different repository than crates.io, which can have different naming policy

ithkuil 6y ago

This is why I like the Go approach: just use an existing global namespacing system and delegate to it all ownership disputes etc: DNS + actual web servers serving traffic (not necessarily just got repos, since the "vanity imports" offer an indirection based in html meta tags)

steveklabnik 6y ago
Yes, there are benefits to that approach. We rejected it because we want builds to be reproducible, and not to have that property depend on external entities.
- ithkuil 6y ago
  That's orthogonal with the naming scheme. In fact the Go team eventually implemented a way to decouple the storage of a copy of the package from the name of the package, namely the goproxy. How they got there was admittedly a bit clumsy, but it proves that it's possible
  - steveklabnik 6y ago
    Sort of; you can still delete github repos and the proxy doesn't keep a copy forever, right?
    - ithkuil 6y ago
      That's an implementarion choice of the proxy. You can run a private proxy that inplementa whatever policy you want. If crates wants a policy that stores crates forever then just store crates forever. What I'm talking about just affects how new crates and new versions of existing crates get "uploaded". Imagine you call your crate foo.com/bar. In order to push your crate the crates server needs to verify that you actually own the foo.com/bar URL. There are many ways to do that. A simple one is to just have the crates server pull code from that URL instead of pushing it. If you want to push (e.g. to work around reachability issues such as firewalls) it's just the matter of devising one or more ways to prove that you "own" that handle. For example by serving some challenge response in a html meta tag

didibus 6y ago

I hate namespaces like everyone else, because they're inelegant and kind of uncool. dependencies: regex Vs dependencies: com.cooladtech/regex But the world doesn't let us have it elegantly, because the library with the name "regex" will almost never be the regex library you want to use. It will almost never happen to be the best, most maintained, best documented, highest performing, with all the regex features you need library. So instead, the regex library you want will be called "potato". Like a hot potato, potato doesn't let you down when parsing regex. And then there's the issue of groups of packages that generally make sense together, and no good way to define those groups. So you might have: regex_core regex_engine and regex_api, but it turns out regex_api is for another package and not really part of the group. Anyhow, back to the article... Identity? So I read and re-read the section on identity, and I'm not sure what they're saying, it seems they're saying that not having namespaces makes identity worse for discoverability? So basically it argues for namespaces? Now I'm confused... > A flat registry makes identity management (naming a crate) harder Than for continuity, it seems to say that if you have a namespace it's bad, because you could confuse two packages of the same name, but in different namespaces? Okay, I did see this sometimes, mostly in tutorials where they don't list their dependencies, but only their import statements (and sometimes they don't even list the imports). So the reader is kind of left figuring which "regex" lib they are supposed to choose since it exists in many places. But then the post also says that the lib name can differ from the package.name already? Which means you can already have the same lib name for two different packages in Crates? So I'm confused again? > Updating to a new package version with different content under different ownership is a real security risk I have no idea how this would happen unless I manually changed the dependency to point to the one from somewhere else? So I really don't get the risk here. > Doubly so if you don’t ban new minor versions on the last major version after an unintentional ownership change Okay, hold on a second. I don't think this article is debating what I think having namespaces mean. Here it seems like the article imagined a world where you depend on the package name and do not specify a namespace, and then in crates.io someone could transfer the ownership of the package to someone else. Or something like that? This makes zero sense to me, I need someone to explain it to me. > This is a strike against schemes that encourage multiple distinct crates to have the same default name in code. I don’t think any proposal that encourages this could be approved. Okay, now we're talking. This is a GREAT point. Obviously, the import statement must include the namespace as well. Otherwise you can depend on two packages and have import conflicts where who knows which module you're getting? But is this about namespaces? Maybe the argument here is that the way Rust work, this would not be the case, thus risky? If true, I think this is a defeating argument honestly, something has to be done about this. Also it sounds like this is already a problem, because lib name can differ from package name? Anyhow, I'd direct people to this amazing post from the Go world, and I think they got everything right when it comes to their view of package management: https://research.swtch.com/vgo-principles https://research.swtch.com/vgo-principles

hevelvarik 6y ago

I don’t know Rust but have learned enough about it to know that lack of namespaces in crates.io and anything at all Rust related Is inarguably a feature

hombre_fatal 6y ago

It's actually terrible, justs look at NPM and RubyGems. Instead of just coming up with a good name for your project, you have to come up with a unique one even though the project with that name isn't even active. And since most names are taken, you have to come up with a clever one for no real reason. Or go down the route of naming strats you see on npm/gems: better-lib, lib2, lib2-better, lib3, better-lib3, etc. It really does nobody good except for the person who was able to clutch the original name, and that's a weird incentive structure. Subreddits have this same problem where you're instantly gimped when named anything other than r/bitcoin, r/politics, r/news, r/atlanta, etc. Instead, there should be no preciousness to names nor dictionary words. That's the correct incentive structure: none. People keep linking https://crates.io/users/swmon https://crates.io/users/swmon and it probably seems like an easy fix to just revoke those names. But swmon isn't the problem, the system is. It's no bigger problem when swmon does it overtly vs thousands of people doing it incidentally when they register a package they don't do anything with. The problem isn't to calibrate a system that can detect swmon but build a system where you don't care what swmon does. What you want is something like this: https://package.elm-lang.org/ https://package.elm-lang.org/ Watching Crates get this wrong was like watching Swift not implement qualified imports.

tikhonj 6y ago

> So what’s a bad actor? I consider someone who squats a bunch of crates to make or point or prevent their names from being used to be a bad actor. In my experience, the thorny problem with namespaces isn't bad actors because you can fix that with content moderation. Yes, that takes time and effort which can be scarce in an open-source community, but it's doable. No, the thorny problem is good actors with bad execution: people who publish a package with a nice name that does what it says it does, more or less, but does it poorly. It doesn't cover all the edges case or it is poorly optimized or it has limited features or it has some fatal design flaw in its architecture... Maybe it was fine at some point but just hasn't kept up with the times. So what do you do if a package like that grabs the name "json" or "http" or something? You don't want to kick packages off just for not being great, but you also don't want it to seem like the de facto package for a task in your language. I do a lot of Haskell, and it's not the best developer experience when you have to tell people "don't use json, use aeson instead". Namespaces would solve this problem. You could have a "blessed" namespace (like rust/) and, when functionality becomes important enough that the quality of the "default" package matters use the namespace to provide that package (rust/json, rust/http... etc). You don't have to kick off the existing package (even if it's squatting a "nice" namespace like json/json) but you also don't get into the point where packages with nice names look fine but are actually flawed and a bad choice for real work.

solatic 6y ago

If anything, namespacing doesn't go far enough. We have a wonderful namespacing mechanism already for the Internet - it's called DNS. We use DNS validation as a security foundation for issuing TLS certificates. Package registries should allow me to "own a domain" - backed up by DNS validation - and upload packages under that name. "Domain ownership" should be paired to a timestamp issued at verification time, so that a) package uploading can be blocked entirely if the DNS verification is lost, b) consumers can continue to download packages under the old domain timestamp c) domain ownership can still transfer as needed d) changes in ownership are tracked, and consumers are notified. Why does everybody always have to reinvent the wheel? DNS has been around for decades. Using DNS records to verify ownership has been around since, what, the early days of the ACME protocol in 2014/2015? Earlier?

steveklabnik 6y ago
DNS records have a financial and technical barrier to account and package creation that we found unacceptable; and those costs are ongoing, leading to an unacceptable level of mutability.
- solatic 6y ago
  Well, you don't have to only accept DNS records! It's like arguing that independent email providers shouldn't provide general addresses like @gmail.com or @fastmail.com if they're going to provide any support for custom domains. You could do both. In fact, offering support for custom domains is usually an opportunity to up-sell, particularly to the kind of customers who have already shown that they're willing to spend money on an on-going basis (by paying for the DNS name).
  - steveklabnik 6y ago
    I’m still not sure how that solves the problem, but regardless, the point is that there are many possibilities and tons of complexity. It is not a simple, unambiguous problem with a clear correct answer.

gbear0 6y ago

It sounds like both flat hierarchies and namespaces won't work cause both sides have fundamental problems that can't be solved in a way that everyone agrees upon. So what about combining them and having the best of both worlds? I think the docker namespace schema provides a great way to have a 2 stage lookup where the first part of the id (up until the last '/') is a full url to the registry, and the last name in the id is the flat hierachy of names for that registry. In fact this scheme is already supported with cargo since you can specify the registry per dep. This means the default registry, if nothing is added is 'crates.io/' but you can specify any other registry, eg 'gitlab.local/looks/like/namespace' for personal CI, or even 'crates.io/{username}' Let's give each user their own registry at 'crates.io/{username}'. This works in a backwards compatible way cause registry:'crates.io/' + crate:'mypackage' is different than registry:'crates.io/mypackage' + crate:'mypackage', so nothing changes with the current crates and it's all an incremental implementation detail for crates.io Now we have the npm user style namespace ids that lessens the namesquatting problem, but increases the security issues if the registry changes hands. Honestly, I've never really understood the security argument here cause there's no reason an owner can't hand over a single package. As well, there's no reason a currently trusted owner can't patch update a package with bad code. This is a social problem that has no solution and is the same for both naming systems, so we need to come up with another way of handling things. Personally I think all published crates should be immutable and all deps should be pegged, not even allowing patches. But this leads to the argument that sometimes publishers really do want to take down a crate. I'm on the fence with this one, so let's try to solve it in another way. So the problem is we need to potentially remap any (transitive) dependency to something else, and since we still have a flat hierarchy we really just need to remap the registry for that dependency. So let's add a registry remapping section for the cargo deps ... wait cargo already has something for that (https://doc.rust-lang.org/cargo/reference/source-replacement.html https://doc.rust-lang.org/cargo/reference/source-replacement...). (Reading through the docs here, it does seems like it might be a little strict on whether we can use it for this case, but it's pretty close.) OK wrapping up, it looks like we could have backwards compatible namespaces right now if crates.io would just implement user specific registries, ie it's an implementation detail. And the security issues are really no different than before. Thus I've got to ask, what am I missing?