Create 0000-cargo-dns.md

[hydroper]

Rendered

[programmerjake]

maybe it would be better to put all dns names under net:: (since net isn't used currently), e.g. example.com would be net::com::example and sub.example.test would be net::test::example::sub

[programmerjake]

and if the repo's ip address was 1.2.3.4 it'd be under net::arpa::in_addr::_1::_2::_3::_4 (based off reverse DNS lookups)

[clarfonthey]

I dislike this change for the same reason that I hate it in Java and co., and I especially dislike it in Go!

This introduces all sorts of nonsense issues like:

• Our organization has a dot-com and a dot-org domain. Maybe some packages should go under one, and some under the other? In that case, there's no top-level link to the same organization any more.
• At what part does the host end and the resource begin? (e.g. for io.github.rust-lang, does this mean rust-lang.github.io or github.io/rust-lang? this is why GitHub uses .io for pages and .com for repos, but it's not a good reason to use this system, just a hack to get around it)
• What benefit do we get from having to type five extra letters before every package name? (com::, org::, etc.)
• What if a project's URL changes? Should the package name change too? (this is why I especially hate it in Go; the project URL is the package name, meaning that changing that is a breaking change)

And all of this for… what, exactly? Don't get me wrong, I think that DNS can be a nice system for things, but definitely not here.

It's also worth pointing out that the RFC itself is clearly underspecified, since it's not exactly clear how the DNS-based verification will take place. As written, there's nothing stopping me from publishing com::google::package without owning anything related to Google, and while this would get taken down for one reason or another, how many people could I fool/compromise in the process? It's just, a system that only seems simple because it pretends that the massive complexity of DNS itself isn't part of it, and just tacked on.

[hydroper]

Like I said, this is not a required change so far. If it proves to be useful futurely, I leaved my RFC on. The publishing process could be more complex to require registered domains.

[Noratrieb]

This RFC does not describe a problem. Solutions without problems are not useful

[hydroper]

@Nilstrieb I am well aware, the thing is that the future is unknown and it might be good to worry of the net, com and org crates.

[carols10cents]

This is not an urgent or necessary feature currently.

The crates.io team has very little bandwidth, so any non-urgent or unnecessary features are extremely unlikely to happen.

For this proposal in particular, it seems like a separate package registry website could implement this sort of scheme to prove it out first, without needing support from the crates.io or cargo teams. That would be my preference at this time.

[epage]

I'd recommend starting with a PreRFC on internals to help vet an idea and collect input. For example, this isn't acknowledging the existing packages-as-namespaces RFC that is going through FCP for some of the relevant teams. This also should go into more discussion about how this ties into any existing packages this conflicts with.

[Eh2406]

Why are com and org special? What about other top level domains like rs, io and blog? What happens if new top-level domains are added that conflict with existing packages? For that matter, how to handle the existing https://crates.io/crates/com and https://crates.io/crates/org ?

[ahicks92]

Also people are working on namespacing already, so is this mechanism supposed to be in addition to that or replacing it?

We only really need one namespacing solution.

This is also tied to GitHub, and what stops me from just putting a random url in my package's repository field in order to publish under whatever top-level domain I want? There has to be some kind of validation to make this work.

I think that the better solution is to allow users to register names via some UI in crates.io or something, if we did want to go here. If those have to be dns, then maybe also force them to validate via txt records as GSuite and similar do.

In addition to this being unnecessary/low priority, it is very much underspecified. What about cname? Which DNS resolver will crates.io use? What about mirrors and other registries? What's the plan for phasing this in so that it's not a giant slap in the backward compatibility face when a project wants to bump MSRV to migrate to it?

What happens if a domain or GitHub org changes owners? Is that manual? If it's manual, handled by who? How does one authenticate such a claim vs hacking/social engineering?

I could probably think of more but I agree this isn't ready to be an RFC.

[AaronKutch]

Go exemplifies a particular kind of surface level bikeshedding that looks good on the surface and for first pass toy examples, but fails to see the insane non-local turmoil that is forced upon you in the inevitable need to eventually refactor a large project or try to incorporate something modified for your own uses. For example, public/private functions are differentiated by capitalizing the first letter of a function. This has elegant reasons, but assumes that you get your interfaces right the first time, and eliminates the future possibility of things like pub(in mod...) in Rust. Ctrl+F and replace won't save you if it is some commonly named getter or setter. There are other things, but the absolute worst of them is Go's import system. DNS paths are much longer and inherently more difficult to change. When changing just the middle of the paths to change organizations or using different variations of the same analogous suite, it is easy to miss it in one place and have the old thing still being used without you realizing. I have personally encountered the intense displeasure of moving repos and trying to find the magical combination of go mod tidy, go mod vendor, replace =>, and potentially needing to change all URL instances anyway to get the specific repo and commit I want. The Rust Cargo.toml feature I always want to reach for is either the git+rev or path+ a workspace, which just works™ on the first try, >95 percent of the time. Changing it requires merely one point. Plus there is as renaming in the source code and other advanced Cargo features like #3529 that handle rarer cases.

[ahicks92]

Well, even with this RFC I believe that the config goes in Cargo.toml anyway so that's not a concern. Worst case you just don't compile anymore, there can't be hidden internal dependencies to a module.

Now that said looking at this again, to add one more thing to the problem pile, you can't rely on the org and com packages not to publish a new release. It's not sufficient to say that it's illegal to publish a package which conflicts with an item exported by those crates because those crates can change their mind tomorrow. It's also almost certainly a lot of work to make anything remote understand the current state of those crates without building them, and of course there's also all the old versions people might depend on as well. I'm not a fan of this RFC at all, to be honest, but at least as regards this part of it the only sensible thing you can do is say that it is not valid for a user to depend on both some package a and also some package a::b. Everything else (e.g. validation, allowing it to work if there's not overlaps) relies on a being a well-behaved member of the ecosystem and taking on additional constraints such as never adding a new module with a short, generic name.

It's not necessary for anyone to own their own domain name either. You just need a way for a user to register some sort of namespace--if Google really is attached to this whole com.google.bla thing they can go register com_google or something. We don't currently have any namespacing at all and I don't know which of many things is the latest iteration of that, but "you own this top-level name congrats" is a much simpler solution, no need to tie it to dns.

[carols10cents]

This needs more iteration in a pre-RFC on internals before it's ready for discussion as an RFC here.

@rfcbot fcp close

[rfcbot]

Team member @carols10cents has proposed to close this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @JohnTitor
• @LawnGnome
• @Muscraft
• @Turbo87
• @arlosi
• @carols10cents
• @ehuss
• @epage
• @hi-rustin
• @joshtriplett
• @jtgeibel
• @mdtro
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[SOF3]

It is confusing whether we are talking about a Cargo policy or a crates.io policy. If it is just for crates.io, all users are already authenticated through GitHub anyway, and I don't see why additionally using DNS helps.

[ahicks92]

That's not particularly relevant and is one reason this RFC is underspecified. While it is the case that crates.io auths via GitHub, you may put whatever you want in the repository field including links to non-GitHub repositories and repositories you don't personally own.

[hydroper]

I like domains due to readability and closeness to application IDs:

• com::ea::n4s versus ea::n4s
• org::generalrelativity::foam versus generalrelativity::foam
  • The latter looks like a category rather than an organization name

Relying on GitHub organizations may be removed as part of the proposal in the future. I'm not entirely familiar with domain setup; although I had purchased one temporarily around 2015, I didn't deal with records like you said.

This is an extension to the namespacing proposal, not a replacement, and I don't need to clarify anything in the PR I think.