[Pre-RFC] Domains as namespaces

Coming into this discussion as a result of the “Internals summary” email, it’s no longer clear to me what is being proposed. (I assume it was initially, but the ensuing discussion seems to have resulted in some changes?) I read A) that we’ll be adding a new capability (namespaces, which must be claimed on the basis of a URL) but not changing anything else, and B) that we’ll no longer need to worry about squatting in the existing (global) namespace, but it’s not clear to me how those two things aren’t contradictory.

Since that part of the proposal is confusing, I won’t comment.

What I will say, however, is that having some global crates and some namespaced crates is far from an ideal solution, because global names will always seem to have an air of “special-ness” to them. Some kind of “original crate privilege.” Like how having an implementation of hashids named “hashids” is better than having a crate named “johnny-hashids.” One of them obviously came first, and even if that doesn’t actually make the “original” crate better, it’s something that we–as imperfect animals–still take into account.

To be fair, I pushed for namespaces a long time ago, basically as a result of seeing the proliferation of iron-specific crates with super-generic names like “router.” “iron/router” would have seemed to me to be a lot less abusive of a limited shared resource (like, you know, the global namespace)–but to have them as required going forward (rather than optional) seems to pretty obviously damage the options available to future users of cargo. Furthermore, if they aren’t required going forward, then I don’t see what this solves regarding the idea of squatting.

Reading through the entire thread just now gave me the impression that there are a good number of legitimate problems with this approach and, although there are also potential solutions to those problems here, I couldn’t shake the feeling that they seemed like patches on a tire–ad hoc solutions offered under duress, in the heat of the moment, so to speak. Anyway, if you’re trying to sell me a tire, I prefer a new tire, you know?

I know I sound like an old man, but having a problem does not justify having a solution. Having a problem can justify having the right solution, provided that the unintended consequences of that solution aren’t worse than the problem itself. I understand that one of the great benefits of open source is that we have a large number of people attacking problems from every angle, but we still have to remember that doing nothing is also a viable response to most problems.

So, for now, I still advocate doing nothing.

5 Likes

I like the idea of namespaces, if the existing crates become part of the crates.io namespace, as part of a federated system.

That way, they aren’t special - they’re all just crates on an instance.

Using the short form, without specifying the namespace, would be deprecated and generate warnings, to further move away from the “specialness” of the default namespace - which is only necessary for backwards compatibility reasons.

Much of your own replies to concerns are still not addressed in the main post.

First off just saying "No" begs the question on "Do I need my own domain?" why don't you.

Your own post here: [Pre-RFC] Domains as namespaces - #22 by anon2808951

has a lot of points that are not addressed in the OP, but that you've addressed:

eg:

What’s the plan for referring to namespaced crates in rust code?

which IMO you've properly addressed with:

There isn’t any. This is intentional, because doing this would be a terrible idea. etc...

then there's the refering to crates in cargo.toml, swapping domain depedencies, the potential issues brought up by refering to github.

This also isn't properly addressed : [Pre-RFC] Domains as namespaces - #25 by pythoneer

There is still an impression of things that aren't addressed because there's no closed form "You asked this, this is the answer" here, its scattered through other primarily your own answers and other peoples questions, some of which went ignored (liked the thing I pointed out not being properly addressed).

I wasn’t going to respond, but I just got hit with another deluge of news regarding internet censorship…

I cannot support this proposal or any like it in today’s political climate. My own political views are staunchly at odds with those of the Mozilla Corporation and those of much of the Rust team, and we live in a world where it has become acceptable to de-platform and un-person anyone whose political opinions are deemed incorrect by Silicon Valley. I cannot support any proposal that adds barriers to entry for creating software because software has become an essential element of speech and of the ability to commune with our fellow human beings.

I realize that the current state of crates.io (and other similar systems) is kind of annoying. I’m probably more affected by this than most people, because I create and maintain a pretty good number of libraries, and my first choice for a name is pretty much always taken. Still, I kind of just view it as a chance to be creative. That’s a price I’m willing to pay to allow people to create software and make it available to others without having to jump through hoops or seek the approval of a gatekeeping committee. (Note that I think of the domain-as-namespace thing itself as especially troublesome in light of recent developments, where registrars decide that a domain owner just isn’t allowed to have a domain anymore.)

Thank you for inquiring about my input. I hope you’ll take my concerns into consideration, regardless of what the community does or does not choose to do about this.

Namespaced crates would be unique in one organisation, but different organizations could of course have crates with the same name, often even intentionally.

Nice to heard this. Thank you!

I don’t trust the crates.io maintainers as gatekeepers (and this is not intended as a comment on the caliber of people we have doing that job, but simply a comment on the nature of gatekeeping; I see it as an unnecessary evil where thought and free expression are concerned), but at least for right now I only have to worry about them, and I hope it stays that way: to wit, they have not, to my knowledge, acted as gatekeepers, but as facilitators. If you throw domain registrars into the mix, you compound the problem, adding more points of failure without improving anything–because domain registrars have acted as gatekeepers in the past two years.

The federation idea sounds nice in theory, but it doesn’t work in practice for the same reasons: once you ghettoize this or that registry, it becomes easy to condemn and then de-platform that registry by either A) refusing to ‘federate’ with them (I have no idea what technical details are involved, and you did address this in your response–although I disagree that such a circumstance would be acceptable) or simply B) having their hosting provider pull support.

By having one primary host (crates.io) that does not turn people away, we make it more difficult to take action “B” because the harm done by taking crates.io offline would be exponentially greater than the harm done by removing other, less important registries from the web. (I will note that this is a concern you did not address in your reply because, admittedly, I did not explicitly state it before.)

This kind of namespacing is vulnerable because of the state of today’s web infrastructure. I wish I hadn’t lived to see such interesting times, but we don’t really get a choice about it. :slight_smile:

As long as it remains possible to publish code to some namespace without needing a domain. (I’d personally prefer to keep the global space as it is and add the domains as well) then adding a mechanism for domains on top of that scope means more ways to avoid gatekeepers not fewer. and even the possibility to open up crates to other people to manage in the case where gatekeeping is a problem.

1 Like

This is what I was talking about with that last point.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.