I believe your idea here does too many things at once, and I believe you could/should try to split it up into more minimal ideas for changes.
Some ideas/thoughts for illustration of possible splitting points include… (click to expand):
For example, cargo already supports decentralization in the form of git dependencies. Your proposal reads like you’re suggesting crates.io to become part of a larger decentralized ecosystem, which could mean a crate on there might be able to depend on another crate that isn’t part of crates.io itself.
Currently crates.io does not support hosting crates with git dependencies, or dependencies on crates in other registries. The reasoning behind this is what @epage called “one of the fundamental design constraints of the existing registry system”. If your proposal is to change this property, this can be a feature/discussion on its own, which absolutely doesn’t need to include e.g. any petnames functionality; and conversely petnames could work without the need for changing this design aspect of registries, or crates.io policies.
Another thing that this seems to propose is a more unified way of specifying dependencies. Your proposal reads as if it wants to give crate registries (you sometimes call them “repositories”) a more equal position/rank, next to other sources for dependencies. Currently one important thing that only registries do is to offer versioned dependencies, with semver-based versioning and version resolution, and corresponding tooling. Ways of extending these mechanisms to other forms of alternate sources can be its own feature, too, and would be a necessary precondition (as far as I can tell) for any “Repositories would just be search engines for crates” vision that you might have.
You do give a few design ideas on how to make this work involving signed releases and meta-information shared through custom registries/“repositories”. I believe it would be important for such a proposal to explore the design space a bit more broadly; e.g. one could consider more minimal approaches; for instance:
- some way of including versioning within the git repository itself without a full additional mechanism of custom decentralized-crates registries?
- taking a closer look at the existing mechanism for alternate registries and identifying shortcomings in the existing features/mechanisms when trying to use it for this kind of purpose… as a starting point, one could read through previous discussions e.g. around the RFC that introduced it
You do list a lot of technologies (even open-ended, with a trailing “…”) with “link to any download location, torrent, IPFS”, and of course any new kind of technology (besides the existing ones of git dependencies, and alternative registries). Of course, support for any such technology could be its own feature idea.
IMHO, to get towards any actually useful/realistic/successful proposal, it is pretty much necessary to split this up, into multiple parts/steps. Then you could reflect on what part/step seems most relevant/appropriate/useful to target first, and set focus only making a proposal out of only that that part. (For some more thoughts on paths forward, also check out my final 2 paragraphs in this reply.)
I’m also noticing increasingly – the longer I consider the ideas you bring up here – that there’s a lack of motivation; you only cite a “problem that names on crates.io could not be reclaimed if they are blocked by an abandoned package” (some people might debate whether this is even a problem at all, and “abandoned package” is awfully vague, anyway). Even now, I haven’t really gained any good understanding about what aspect exactly of your ideas is actually involved in making a solution to this problem, and in what way it is solved through petnames in the first place (or whichever other aspects of your ideas here is relevant).
Even for a not-yet-very-detailed kind of idea, it’d be great if you tried to list some drawbacks and alternatives already, and/or identify unresolved design questions. Searching for drawbacks naturally comes with some more research – e.g. into prior discussions – to understand the values & design decisions behind the status quo. It is a bit more effort, but it also makes readers happy that can value if you spent this effort already. Being critical of one’s own ideas (by listing drawbacks and open questions) also sets up for a more productive discussion, anyway:
If someone else comes up with additional shortcomings, you don’t need to feel obliged to address those immediately. If they seem like a reasonable observation on points where a trade-off ends up being made, you can just (mentally or actually) include the list of drawbacks you’ve already identified yourself; if they seem to be based on a misunderstanding of your proposal, they could instead help you identify parts of the proposal that aren’t clear written down sufficiently clearly yet, or you can identify there’s open questions if the drawbacks apply only to potential ways of fleshing out the ideas more concretely.
Looking at some prior discussions, and understanding the status quo, is also very relevant to identifying alternatives. One alternative is often the status quo itself. Other alternatives might already exist in documented “future possibilities” of previous RFCs. Alternatives also help channel your own creativity into a direction that doesn’t just makes the proposal larger and large. And last but not least, to even try and start to be able to lay out alternative solutions to a problem, you will probably notice if you haven’t identified your motivation / motivating problems in sufficient detail.
And perhaps try finding a bit more on prior art as well. You link to a Wikipedia page, but I don’t see any mention of how & where "petnames" are already used for package managers for software libraries. Really proper prior art saves you a lot of work. You don’t need to come up with all the points of motivation, drawbacks, alternatives, etc… yourself, if you aren’t proposing a novel concept, or a novel application of a concept in a different context.
Your choice of “Pre-RFC” labeling for this thread does suggest this might be a serious proposal that you hope could lead somewhere real, which is why I’m giving pointers involving in particular these keywords above that come from section headers of the template for actual RFCs. You already noted that “this proposal still lacks a lot of details”, which is a good observation.
In my experience, a typical “Pre-RFC” post also already tend to either already (roughly) follow the structure of real RFCs, or at least contain more the relevant contents for turning them into an actual RFC eventually. In this thread, I see an unrealistically large scope, and a lack or sufficient real details, and (lack of) considerations regarding the abovementioned keywords/headers (i.e.: motivation [in sufficient detail], drawbacks, alternatives, prior art), so writing an actual RFC doesn’t seem like the best next step to take.
So I hope it makes sense that I’m changing this topic’s title to remove the “[Pre-RFC]” prefix 