Pre-eRFC: Crate name transfer

internals policy
1



A real RFC has been opened as RFC 2614. A pre-RFC draft is preserved below.



Summary

This experimental RFC proposes a process by which a designated Rust team member or members could reassign ownership of a crate name on crates.​io. The aim is to identify the absolute smallest, most conservative step we can feasibly make from the status quo of crate names that can only be transferred by a current owner. The proposal is intended to address only the absolute most clear-cut situations in which a crate name would need to be transferred. It is not intended to address the situation of name squatting on crates.​io, nor as a gateway to eventual more aggressive forced exchange of crate names.

Motivation

It is my humble belief that there exists such a thing as a clear-cut situation in which transferring a crate name from one person to another makes sense.

The following situation describes a real crate (all of the following describe the same crate):

  • Crate was last updated 4 years ago,
  • Not a single version of the crate compiles on any Rust compiler 1.0.0 or newer,
  • In the most recent version of the crate, the author has indicated that the entire crate is deprecated,
  • Zero other crates depend on the crate,
  • Crate has a desirable name that a different user is eager to use for a library that is all ready to be published,
  • Reasonable efforts to contact the author are unsuccessful.

This eRFC introduces an opportunity for a Rust team member to be entrusted in volunteering their time and their reputation to improve the experience of using crates.​io by arbitrating similarly clear-cut cases.

Experiment

This RFC proposes evaluating the process outlined below as an experiment that can be abandoned at any time with or without cause.

Any Rust team (core team, or subteam with representation on the core team) is welcome to call off the experiment at any time if they perceive undesired fallout from the experiment, or for any reason whatsoever. Such a decision would be arrived at by that team's ordinary decision-making / consensus-reaching process. The safeword is as follows:

The [your-team-name] team believes it would be better to discontinue this experiment and would like to stop fulfilling crate transfer requests effective immediately.

No justification needs to be given; the activities described in this RFC will terminate without further discussion.

This termination condition is intended as a lightweight way to avert or contain unforeseen impact of adopting this experimental RFC.

Reference-level explanation

The library team and/or moderation team will designate a Responsible Party. Crate transfers happen at the sole discretion of the Responsible Party.

The Responsible Party need not be a member of the library team or moderation team. There may be more than one Responsible Party, in which case the Responsible Parties will need to agree among themselves on a consensus process for approving crate transfer requests. If the Responsible Parties cannot agree, they are deemed Not So Responsible After All and the experiment terminates.

To reiterate: crate transfers happen at the sole discretion of the Responsible Party. There is no checklist of criteria that decide whether a request is granted. The Responsible Party is entrusted with upholding the intent of the eRFC in performing transfers in only the absolute most clear-cut cases according to their judgement.

When a user requests ownership of a crate, the two possible responses by the Responsible Party are:

  1. All right, I yanked the existing releases and set you as the owner!

  2. Hi! Thanks for the request. I believe this case is less clear-cut than the ones I am currently willing to grant. I would recommend picking a different crate name for now, but we can leave this request open if you want and revisit the decision in the future.

The Responsible Party is encouraged to respond to requests in a timely manner, but realistically they will respond when they have time and mental energy available.

Guide-level explanation

The details of requesting ownership of a crate name are to be figured out over time, but a viable way to begin would be as follows.

  • Set up a repository under The Rust Programming Language · GitHub called "crate-transfers".

  • Write a readme outlining the process. Ensure that the readme conveys that only the most clear-cut requests will be granted, so not to expect too much.

  • Requests are made by filing a GitHub issue.

  • Include a list of "up for grabs" crate names in the readme. Authors that no longer wish to use a crate name that they own can add it to the list by filing an issue or sending a pull request. A crate that is "up for grabs" trivially meets the "clear-cut situation" requirement if ownership of that name is ever requested.

  • Decision to terminate the experiment may be delivered by filing an issue containing the safeword message above. A pre-prepared note will be added to the readme and the repository will be archived.

Drawbacks

What if people get mad at the Responsible Party?

People are welcome to get mad at any Rust team member at any time, although this is not encouraged. The Responsible Party needs to be willing to stake their reputation on their ability to make the best decisions, and must be willing to take the fall if things go bad. Some experiments fail.

Checks and balances exist, particularly as any Rust team may terminate the experiment with or without cause.

What recourse is available if somebody is unhappy with a decision?

The usual:

  • Complain on Twitter.
  • Blog about it.
  • Strategically upvote and downvote on Reddit.
  • Email the mods.
  • File lawsuit.
  • ...

None of this is different from any other team decision that may make a person unhappy -- the libs team breaking your code, or the moderation team deleting your flame war for example.

This RFC does not go far enough.

This eRFC is not intended as a solution to the name squatting situation on crates.​io. This eRFC does not denounce the behavior of registering crate names without the intention of using them.

By taking this step, it may be perceived as a decision against ever addressing the name squatting situation more decisively. That is not the intention of this eRFC.

The volume of requests may be overwhelming.

If the volume of requests is overwhelming, that would be sufficient reason for a team or the Responsible Party to terminate the experiment.

Rationale and alternatives

Alternative: provide a checklist of criteria

"The crate must be X years old, must not have crates depending on it, must be below version 1.0, must ..."

I believe it is better to leave the decision entirely up to the Responsible Party with no checklist. Similarly, the lang team does not have a checklist that determines what language changes are made ("must use no more than two new keywords, ...").

Alternative: require quorum greater than one

This eRFC allows for there to be multiple Responsible Parties as designated by the libs team and moderation team, but I believe that a single one is sufficient to achieve the aims.

TODO:

I need to read the 2500 existing comments across the various name squatting threads to see whether there are alternatives I should mention. I have not followed those threads and this eRFC is not intended to address name squatting.

Prior art

Unknown. I am interested to hear experiences from other package ecosystems.

Unresolved questions

Let me know!

Future possibilities

This eRFC would like to avoid, as much as possible, any association with a name squatting policy. Such a policy should be a largely orthogonal RFC.

As much as this is not the objective of this eRFC, the way this experiment plays out will likely inform any future policy on squatting.

8 Likes
2

:+1: to the idea, but I think it’d be better to have a small (2-3 person) team for this rather than a single individual.

I definitely agree with taking the smallest possible step, handling cases where the maintainer is truly unreachable and development is dead.

Without specifying criteria, I will also observe that this process should take into account the reputation of the person asking; an existing crate should not be handed over to someone with zero reputation.

I also think it’d be worth exploring technical solutions that would make this smoother, such as the ability to maintain the crate under a different name and have the crates.io index include some kind of “requests for X can be satisfied by Y” mechanism that can be revoked in the future.

2 Likes
3

As one participant of the name-squatting threads, I think this would be a great first step. I do agree that having a small team might be good, because sharing these kinds of responsibilities can be easier towards the public as well as preventing some kinds of partiality.

Without specifying criteria that are exhaustively evaluated, I think it might still be useful to list some suggested criteria and possibly also some suggested non-criteria, which can serve as guidance for Responsible Parties. (Even if only to serve as institutional knowledge of the many suggestions that people have made and preventing a whole lot of bikeshedding on what might serve as a criterion.)

1 Like
4

This proposal seems to mainly address the "abandoned is hard to define" objection, which is great.

There was also another important objection in the squatting megathread:

Can we do more on that front to shield the Responsible Party from requests?

1 Like
5

Thanks for the feedback! I would like to clarify a few things before I update the document.

@josh

I think it’d be better to have a small (2-3 person) team for this rather than a single individual.

Would you be able to call out some reasons that a 2-3 person team would work better?

Is it about being equipped to handle the thorny situation of the single individual themselves wanting to claim a crate, then granting their own request? Is it about more continuous coverage when the individual is busy with other things? For both of these it would be sufficient to have a team of 2-3 but quorum of 1, meaning any one of the team may grant a transfer request.

Or are you concerned about unilateral decision making and would want to require a quorum of more than 1 person agreeing to grant the requests? If so, would you want to require quorum greater than 1 in all cases, or only in borderline cases?

Even with only one person involved, I have tried to structure this such that they would be incentivized to be as cautious and conservative as possible. The boundary of what is considered clear-cut should only move extremely slowly over time.

Without specifying criteria, I will also observe that this process should take into account the reputation of the person asking; an existing crate should not be handed over to someone with zero reputation.

Interesting! What is the concern here as compared to registering crates that were never claimed in the first place, for which there is no requirement of reputation?

In my mind the clear-cut cases are ones where we can effectively consider the crate to never have been registered.

Is the concern something to do with exploiting existing users of a crate by releasing malicious patch versions? It seems unlikely that a crate that might possibly have existing users would ever get transferred under this process.

@djc

I do agree that having a small team might be good, because sharing these kinds of responsibilities can be easier towards the public as well as preventing some kinds of partiality.

This is the most sensitive part of the RFC so I appreciate the feedback. You've been pretty clear here but just to confirm with some examples -- you are considering the case where a community member requests a crate and believes their request was denied because of some pre-existing personal grievance with the individual evaluating the request? Another example: community member believes a request was granted when it shouldn't have been, and it was because the requester is personally acquainted with the individual evaluating the request?

If so, do you believe it is necessary to have at least two people involved in every decision as oversight against personal grievance and personal relationships playing a deciding role?

Would accountability to the Rust teams (any of which could terminate the experiment at any time) provide sufficient mitigation here even if there is only one person responsible?

Without specifying criteria that are exhaustively evaluated, I think it might still be useful to list some suggested criteria and possibly also some suggested non-criteria, which can serve as guidance for Responsible Parties. (Even if only to serve as institutional knowledge of the many suggestions that people have made and preventing a whole lot of bikeshedding on what might serve as a criterion.)

Thanks, I will do this. Good call on the bikeshedding.

@kornel

Can we do more on that front to shield the Responsible Party from requests?

I tried to address this under the heading "The volume of requests may be overwhelming".

It would be unfortunate to block the RFC because of a chance of there being too many requests. If we try it and there actually are too many requests, then we can cancel and re-evaluate.

I would prefer to see it the other way around: we try the experiment under the possibility of there not being too many requests.

6

I like the idea and it is a good step forward. Though i feel the conditions given for a crate to be considered for this will rule out many abandoned crates.

7

Yes, those are very good examples. My intuition is also that the small team will constitute negligible overhead in the really clear-cut cases, and will prove valuable in the less clear-cut ones.

8

I vote towards a single person.

Suggestion: A rule that if the experiment is terminated for a reason by a team, and that reason given by the team is you made a bad call, then that call can be reversed and ownership restored to a previous state.

9

I think it’d be better to have a small (2-3 person) team for this rather than a single individual.

Would you be able to call out some reasons that a 2-3 person team would work better?

Is it about being equipped to handle the thorny situation of the single individual themselves wanting to claim a crate, then granting their own request? Is it about more continuous coverage when the individual is busy with other things? For both of these it would be sufficient to have a team of 2-3 but quorum of 1, meaning any one of the team may grant a transfer request.

Or are you concerned about unilateral decision making and would want to require a quorum of more than 1 person agreeing to grant the requests? If so, would you want to require quorum greater than 1 in all cases, or only in borderline cases?

I was imagining a 2-3 person team with a requirement of "two yesses without reservation and zero objections" to grant any request.

I feel like that drastically reduces the possibility of simply overlooking something, because at least two people have to agree. It also avoids having a high-pressure high-burnout position for one person, with an expectation of constant availability.

Without specifying criteria, I will also observe that this process should take into account the reputation of the person asking; an existing crate should not be handed over to someone with zero reputation.

Interesting! What is the concern here as compared to registering crates that were never claimed in the first place, for which there is no requirement of reputation?

In my mind the clear-cut cases are ones where we can effectively consider the crate to never have been registered.

Is the concern something to do with exploiting existing users of a crate by releasing malicious patch versions?

Yes, exactly.

It seems unlikely that a crate that might possibly have existing users would ever get transferred under this process.

On the contrary, I'd fully expect the following as the most common case: "this crate has a handful of users, the maintainer has disappeared and hasn't answered issues/PRs/email for six months, I have a substantial track record and reputation in the community, and I have a repository fork that fixes many outstanding issues; could I become the maintainer and upload a new version?".

I do agree that I wouldn't want to give an existing crate with users to someone who wants to just upload an incompatible crate with the same name. The other common case would be "someone uploaded a random experiment years ago and nobody ever used it, can I use that name". But I'd be far more reticent to grant that kind of request. (The most compelling case there, to me, would be to use the names "foo" and "foo-sys" for bindings to a third-party project named "foo".)

10

“this crate has a handful of users, the maintainer has disappeared and hasn’t answered issues/PRs/email for six months, I have a substantial track record and reputation in the community, and I have a repository fork that fixes many outstanding issues; could I become the maintainer and upload a new version?”

I do not consider this an absolute most clear-cut type of case.

I would prefer for this RFC to be an extremely conservative step and I have tried to emphasize that only absolutely incontrovertible cases would be granted. The example in the Motivation section really is intended to be representative of the sort of case I mean:

The following situation describes a real crate (all of the following describe the same crate):

  • Crate was last updated 4 years ago,
  • Not a single version of the crate compiles on any Rust compiler 1.0.0 or newer,
  • In the most recent version of the crate, the author has indicated that the entire crate is deprecated,
  • Zero other crates depend on the crate,
  • Crate has a desirable name that a different user is eager to use for a library that is all ready to be published,
  • Reasonable efforts to contact the author are unsuccessful.
1 Like
11

I really like the professional style and execution of this RFC.

I have another reason for this: I think the Responsible Parties should act as a team so that, if someone's unhappy about their decision, there's no single individual to be mad at. I hope this will reduce the pressure of these positions.

2 Likes
12

This is my personal opinion; I am not speaking for the crates.io team at this time.

I have a few questions:

  • Do you know of 2-3 people on any of the Rust teams who would volunteer as Responsible Parties, given the experiment you've laid out?

  • Would we mandate that the next version published be a major version bump from the last yanked version, to lessen the likelihood that someone depending on the crate would cargo update and get a crate owned by someone new that they didn't want?

  • As far as implementation details in crates.io's codebase go, it sounds like the simplest way would be to hardcode the Responsible Parties as unexposed owners of all crates... would that be acceptable? There's only a small handful of people who have full database access to crates.io, and I think it's prudent to continue to limit the number of people and the number of reasons to go mucking around in the database directly. I'd also like to make sure, before starting this experiment, that crates.io gets better logging of actions such as yanking so that we can audit who took over what crate at what time if disputes arise.

5 Likes
13

See also this Pre-RFC which addresses the same issue:

For prior art take a look at PEP 541.

UPD: fixed the Pre-RFC link.

14

Do you know of 2-3 people on any of the Rust teams who would volunteer as Responsible Parties, given the experiment you’ve laid out?

Important question! I would like to do it myself if I have the blessing of the libs team.

For now I still think a single person would be sufficient, but I intend to give it some more thought considering the comments so far. Even in the case that we decide to have more than one person involved, the work need not be split evenly between them.

Would we mandate that the next version published be a major version bump from the last yanked version, to lessen the likelihood that someone depending on the crate would cargo update and get a crate owned by someone new that they didn’t want?

Yes we should. Will mention this when I update the document. Thanks!

As far as implementation details in crates.io’s codebase go, ...

I agree with all of this.

3 Likes
15

Thanks for all the feedback. I went ahead with a real RFC: RFC 2614. We can continue the discussion there!

1 Like
16

I thought that might be the case, but wanted to check :slight_smile: I really appreciate that you're volunteering to do the work proposed here; so many proposals along these lines add work and say that people other than the proposer will take that work on. So thank you :heartpulse:

17

I would be willing to be part of a 3-person team working on this.

1 Like
18

I would also be willing to act as a Responsible Party, if the responsible teams would want me to (I am not a member of any of the teams).

19

I am willing to be part of this as well

20

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