[Pre-RFC] Domains as namespaces

[liigo]

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!

[soc]

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

Agree. This could be fleshed out a bit. Subdomains are sufficient. Everyone participating here already owns one, and I think they are not hard to come by.

This also isn’t properly addressed : [Pre-RFC] Domains as namespaces

I think this is addressed in the FAQ. This is largely a policy decision to make. (E. g. archive the namespace altogether, only block that specific crate name, ask crates.io maintainers to create forwarders to a maintained namespace etc.)

Rest assured, if I’d design the database tables, these things would all be accounted for from day one.

---

Thanks for your reply, let me know if there are additional issues you want to see addressed!

then there’s the refering to crates in cargo.toml, swapping domain dependencies

Thanks, these are good points! I will write some documentation about that.

the potential issues brought up by refering to github

Can you expand on this?

[soc]

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.)

This is a good point. I’m wondering though how this is worse than having non-namespaced crates only. Either you trust crates.io maintainers or you don’t … then neither the present situation nor a future one might be acceptable.

I think that having this kind of namespacing would be an improvement, because you could potentially have multiple registries, and the namespace would guarantee that there wouldn’t any clashes – in the worst case some namespace/crate might no be published on registry A, but only on registry B – but that’s it. There would never be a case where different registries would diverge into different, incompatible directions by having incompatible crates with the same namespace/cratename.

[archer884]

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.

[storyfeet]

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.

[Cazadorro]

It sounds like we would end up encouraging many users to use their github pages subdomain as a namespace. That wouldn’t create a hard dependency in theory, but it might in practice. It’s worth considering at least.

Absolutely. Though I fairly certain that most established projects will prefer using their existing domains and many people who might want something “nicer” than “xyz.github.io” will do the same.

My main motivation here is that this approach is more open than e. g. using your GitHub name/org as a namespace as it has been suggested in the past.

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