hey

[meriadec]

I didnt find any other way to contact you, so ignore the PR :)

I want to use the crate name yay, which is registered by you on crates.io https://crates.io/crates/yay

Please let me know how to proceed!
Thanks a lot ! 🎉

[ice1000]

I want to use the crate name ls, which is registered by this guy on crates.io as well https://crates.io/crates/ls

This guy is dead

[AltF02]

disappointing

[JavaDerg]

that person is gone

[boehs]

Likely wanted payment anyway

[ice1000]

I guess somehow we could contact the maintainers of crates.io to take the names away

[meriadec]

@swmon from all the devs that actually want to build stuff from the crates names you squatted:

Fuck you.

❤️

[boehs]

@swmon from all the devs that actually want to build stuff from the crates names you squatted:

Fuck you.

❤️

Ayy I think we can all get behind that

And, a more respective please stop being stubborn and release empty crates to @rust-lang

Proposals

• If a crate has less than 3kb of code and has no changes for 6 months, it is released
• If a developer has two crates where more than 90% of the codebase is identical and no updates for 6 months notify them, wait a month, than, release the one with less downloads
• Offer a repo to vote on forced removal of crates. Ideally, in a similar democratic form to rust-lang/rfcs using something like support and oppose keywords.
• For crates created without a email, release after one year if downloads/month <1000
• A ratelimit of one crate a hour

[boehs]

Another note, this will be the end of crates.io if a solution is not fixed. I can not believe this problem has been ignored for almost 3 years. What if I crawled crates.io registering every crate with dummy content? Would that still be protected? It will happen eventually, then you will be scrambling unless this issue is resolved before then

[JavaDerg]

@swmon from all the devs that actually want to build stuff from the crates names you squatted:

Fuck you.

heart

Ayy I think we can all get behind that

And, a more respective please stop being stubborn and release empty crates to @rust-lang

Proposals

* If a crate has less than 3kb of code and has no changes for 6 months, it is released

* If a developer has two crates where more than 90% of the codebase is identical and no updates for 6 months notify them, wait a month, than, release the one with less downloads

* Offer a repo to vote on forced removal of crates. Ideally, in a similar democratic form to rust-lang/rfcs using something like _support_ and _oppose_ keywords.

* For crates created without a email, release after one year if downloads/month <1000

* A ratelimit of one crate a hour

The crates.io team has made it clear that they will not remove crates no crate squatters.
And there is a better solution to all of that, adding namespaces (or scopes).
We would have a legacy scope that is essentially everything we have right now, and future packages would be released as @user/crate or a similar format, this probably doesn't even need big changes in cargo it self.
This needs to be explored further as it still has some issues.

[boehs]

Legacy crates are also not smart, old "legacy' crate owners will now be able to sell mainspace crate names for even more. Personally, I think we should have "good crate nominations" (somewhat like wikipedia's [[WP:GA]]).

The steps would be as follows

• Legacy crates are moved to userspace (Legacy crates = LC)
  • Their place in mainspace acts as a "Legacy redirect" to the crates place in userspace
• New crates are developed in userspace
• If the crate is good and meets GC (Good crate) criteria, it can be nominated by the crate owner or anyone else to become a GC
• Good crates act as a mainspace redirect, say a GC is developed at bob/random, once it becomes GC random redirects to bob/random
  • If a Legacy crate exists with the same name we ???
    • Option one: Overwrite
    • Option two: Force the new GC to implement the features of the LC for compatibility if the scope is the same
      • If not, Option One

[JavaDerg]

Removing old crates is no option, nor changing their name It will break other crates or applications!

[boehs]

GC base criteria pass one

A good crate must be

1. Well Written
   1. The crate utilizes best coding practices
   2. The crate uses stable rust always
   3. The crate uses functions, traits, and moduals to organise the code
   4. All code in the crate is formatted and linted
   5. The crate compiles
   6. The crate has wide test coverage
2. Open
   1. The crate is open source
   2. The crate is licenced under a open source licence
   3. The crate's maintainers are responsive, addressing issues and prs within a reasonable timeframe
3. Broad in coverage
   1. The crate implements it's main goal
   2. The crate understands its goals
   3. The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate
4. Stable
   1. Breaking changes are rarely created
   2. The crate has a understandable release process
5. Documented
   1. All public code is documented

[JavaDerg]

Legacy crates are also not smart, old "legacy' crate owners will now be able to sell mainspace crate names for even more. Personally, I think we should have "good crate nominations" (somewhat like wikipedia's [[WP:GA]]).

The steps would be as follows

* Legacy crates are moved to userspace (Legacy crates = LC)
  
  * Their place in mainspace acts as a "Legacy redirect" to the crates place in userspace

* New crates are developed in userspace

* If the crate is good and meets GC (Good crate) criteria, it can be nominated by the crate owner or anyone else to become a GC

* Good crates act as a mainspace redirect, say a GC is developed at `bob/random`, once it becomes GC `random` redirects to `bob/random`
  
  * If a Legacy crate exists with the same name we ???
    
    * Option one: Overwrite
    * Option two: Force the new GC to implement the features of the LC for compatibility if the scope is the same
      
      * If not, Option One

I don't mean we should lockup the legacy space, it will continue to exists as rn.
Its over, you cant change it anymore, deleting or renaming any crate is out of the options.
We should add a namespace system where organizations and users can create or request their own namespace to put stuff under.
Request specifically to avoid squatting as the same rules should apply.
Additionally a way to move a crate from one to another space should be possible (all trough not into legacy space) just into or across existing spaces. The old crate will then link to the new one, resolving the old one will make you download the new one and print a warning.

If you want to change this open up a RFC, this has already been done but the author just disappeared and closed the RFC killing it by doing that.
(Keep in mind deleting or renaming is out of the options)

[JavaDerg]

GC base criteria pass one

A good crate must be

1. **Well Written**
   
   1. The crate utilizes best coding practices
   2. The crate uses stable rust always
   3. The crate uses functions, traits, and moduals to organise the code
   4. All code in the crate is formatted and linted
   5. The crate compiles
   6. The crate has wide test coverage

2. **Open**
   
   1. The crate is open source
   2. The crate is licenced under a open source licence
   3. The crate's maintainers are responsive, addressing issues and prs within a reasonable timeframe

3. **Broad in coverage**
   
   1. The crate implements it's main goal
   2. The crate understands its goals
   3. The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate

4. **Stable**
   
   1. Breaking changes are rarely created
   2. The crate has a understandable release process

5. **Documented**
   
   1. All public code is documented

Well Written
    The crate utilizes best coding practices - hard to filter fox
    The crate uses stable rust always - why though? whats wrong with nightly?
    The crate uses functions, traits, and moduals to organise the code - yes
    All code in the crate is formatted and linted - doesn't matter
    The crate compiles - no way to be sure, some crates need dependencies and wont compile on a system without, could also be a platform specific crate
    The crate has wide test coverage - not applicable to all, probably most, crates
Open
    The crate is open source - yes
    The crate is licenced under a open source licence - yes
    The crate's maintainers are responsive, addressing issues and prs within a reasonable timeframe - maybe
Broad in coverage
    The crate implements it's main goal - hard to test for
    The crate understands its goals - hard to test for
    The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate - _you can not stop bloat_ :>
Stable
    Breaking changes are rarely created - that's why we have a versioning system for 
    The crate has a understandable release process - sure
Documented
    All public code is documented - maybe

[boehs]

The crate uses stable rust always - why though? whats wrong with nightly?

Oops, I meant safe

The crate compiles - no way to be sure, some crates need dependencies and wont compile on a system without, could also be a platform specific crate

For a mainspace-worthy crate, I think issues with lacking dependencies is void. I do agree platform-specific may be an issue, but it should be trivial to establish what platform the crate is intended for and test on that.

The crate implements it's main goal - hard to test for
The crate understands its goals - hard to test for
The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate - you can not stop bloat :>

I disagree, determining scope is trivial, just ask what does this crate do?. Than, ask Can this crate do it?. By useless features I mean blatantly, such as a random number crate that has a feature to write the number to a file. This is 100% not needed in the crate.

---

Other than that, I mostly agree. Rev 2 coming soon

[boehs]

1. Well Written
   2. The crate uses safe rust always (unless specifically an extension of unsafe rust)
   3. The crate uses functions, traits, and modules to organize the code
   4. All code in the crate is linted
   5. The crate compiles on its intended operating system
   6. The crate has wide test coverage
2. Open
   1. The crate's source code is available to view
   2. The crate is licensed under an open source license
   3. The crate's maintainers are responsive, addressing issues and prs within a reasonable timeframe
3. Broad in coverage
   1. The crate implements its main goal
   2. The crate understands its goals
   3. The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate
4. Stable
   1. The has been consistently tested to ensure it works before new releases
5. Documented
   1. All public code is documented

---

View changes here: https://www.diffchecker.com/M09oWp6y

[JavaDerg]

Oops, I meant safe

whats wrong with unsafe?

[boehs]

Oops, I meant safe

whats wrong with unsafe?

I have some personal issues with the whole idea of unsafe code, and I have begun switching to rust specifically for, among other things, its safety guarantees. These are personal stigmas, and thinking about it I realize they are meaningless in constituting good library design (additionally I believe it is used in some standard libraries!). Removing.

---

GC criteria draft 3

1. Well Written
   1. The crate uses functions, traits, and modules to organize the code
   2. All code in the crate is linted
   3. The crate compiles on its intended operating system
   4. The crate has wide test coverage
   5. The crate is unique with no obvious code duplication from other crates
2. Open
   1. The crate's source code is available to view
   2. The crate is licensed under an open source license
   3. The crate's maintainers are responsive, addressing issues and prs within a reasonable timeframe
3. Broad in coverage
   1. The crate implements its main goal
   2. The crate understands its goals
   3. The crate does not leave its scope, abstaining from implementing useless features unneeded in the crate
4. Stable
   1. The has been consistently tested to ensure it works before new releases
5. Documented
   1. All public code is documented

[JavaDerg]

I have some personal issues with the whole idea of unsafe code, and I have begun switching to rust specifically for, among other things, its safety guarantees. These are personal stigmas, and thinking about it I realize they are meaningless in constituting good library design (additionally I believe it is used in some standard libraries!). Removing.

Unsafe is fine.
I agree a lot of unsafe can be avoided with good library design, but some things just aren't possible without unsafe.
Crates like SmallVec for example, or implementing an async runtime (because vtables)
You should get rid of that minds.
The point of unsafe is to abstract unsafe operations away safely.
And just is also a systems level language, you need unsafe to even do FFI, otherwise you couldn't talk to c libraries.
If you aren't comfortable using unsafe that is fine, 99.9% of the time you don't need it anyways.

[boehs]

I have some personal issues with the whole idea of unsafe code, and I have begun switching to rust specifically for, among other things, its safety guarantees. These are personal stigmas, and thinking about it I realize they are meaningless in constituting good library design (additionally I believe it is used in some standard libraries!). Removing.

Unsafe is fine.
I agree a lot of unsafe can be avoided with good library design, but some things just aren't possible without unsafe.
Crates like SmallVec for example, or implementing an async runtime (because vtables)
You should get rid of that minds.
The point of unsafe is to abstract unsafe operations away safely.
And just is also a systems level language, you need unsafe to even do FFI, otherwise you couldn't talk to c libraries.
If you aren't comfortable using unsafe that is fine, 99.9% of the time you don't need it anyways.

I understand:), how does draft v3 look? I removed the unsafe section.

[snowfoxsh]

@swmon there is no other way to contact you. I would like to get access to a crate name. Please reply to this.

[orhnk]

@swmon came here to say what I want, but it looks like It's a bit late.