RESERVED.md

I've reserved some crate names on crates.io for future use.

I'm willing to turn over any crate names to interested parties under some criteria:

1. The name actually suits the project. If the crate name is banana and your project is about apples, its off-topic use. Name it apples instead!
2. Your crate is a significant contribution to the ecosystem and not just e.g. some test project or something you never intend to finish.
3. You intend to maintain the crate.
4. There is a RIIR-only policy to help pure-Rust implementations getting great names. This means: no crate names for API bindings of any non-rust codebases, rust-idiomatic or otherwise. There are three exceptions to this rule: OS/driver API bindings, projects that are getting rewritten part by part and where some parts are already rewritten (like ring), and if you are the original creator of the non-Rust codebase and you want to provide the bindings yourself, you'll get the name as well.
5. You actually have it almost done so that its usable by other people. With "usable" I mean that the crate is functional and can be integrated into software fulfilling the task its meant for.

Please get in touch with me if you wish access or have any questions. Thank you!

"Your crate is a significant contribution to the ecosystem and not just e.g. some test project or something you never intend to finish."
you broke your own rule
this is not a significant contribution to the ecosystem

I'm putting up rules, willing to vet access and give it to people who deserve it. That is a valuable contribution in my eyes. So many good names on crates.io were taken by weekend prototypes never intended to be finished or by bindings to c libraries while rust rewrites would have been more valuable. And yes, you need to become a squatter to fight the squatters. That's the only way other than changing the rules which the crates.io team is unwilling to.

Hey, I'm interested in the name "Dirac" that you have reserved.

I'm working on a VDOM for Rust called "Dioxus" (https://crates.io/search?q=dioxus) which I want to release with a state management toolkit. Dirac is a great name since the state management library leans heavily into the concept of "atoms" for state. I originally considered Dyon but that's already taken by a scripting language. Plus Dioxus-Dirac sounds like React-Redux and that makes me happy.

Any chance you'd be willing to part with Dirac?

@jkelleyrtp sounds like a reasonable use for the crate. I've sent you an invite.

Hi @est31 I'm interested in the name "wave". I'm releasing a wav file encoder/decoder lib that supports the majority of extended chunk types, including some of the more esoteric types like PEAK, that are currently missing from current wav libs at the moment. Let me know if this is something you're open to.

Thanks!

@aef- is it on github?

Hi @est31 -- here's the initial lib, there's still some work to be done (documentation, additional tests, a couple of edge cases to handle), will be put in a separate repo as soon as it's named
https://github.com/aef-/audio/tree/main/wave

@est31 I've got a crate that might be interested in the pak name you have reserved. The "pak" format is a custom file type generally used in games and another library I wrote includes a largely feature-complete implementation for baking and reading these files.

I'm happy with the quality of the code, although it is not completely 1.0 yet and doesn't have superb documentation. It does have lots of examples and useful documentation comments:
https://github.com/attackgoat/screen-13/tree/master/src/pak

I think this crate meets your criteria in these ways:

1. The pak name suits my project which reads/writes .pak files, which are commonly proprietary.
2. The "pak"-portion of the existing crate is approximately 90% feature complete and brings numerous capabilities together for users: compression, expressive asset trees common in commercial games, mesh optimization, PBR, scenes, animations, bitmaps, fonts.
3. I have maintained the existing crate, including this functionality, for over two years with a steady and documented plan - I intend to grow this repository further using a new name.
4. The pak code is fully RIIR and even uses .toml to store human-readable asset files. The larger project it currently sits within is another Rust-centric project.
5. The project has reached a point of stability where I hope to see iterative improvements in API, standards conformance, documentation, etc, rather than much base functionality.

@attackgoat invite sent!

@est31 Hi, I'd be interested in taking wave for a no-std no-alloc gesture recognition library intended for usage with low-resolution TOF-sensors. The code is here: https://github.com/flxzt/wave and it would be ready for an initial 0.1 release.

@flxzt invite sent.

@est31 @jkelleyrtp I see at some point you planned to use the "Dirac" crate on Dioxus, is that still the case? I have a dirac notation macro that would fit the naming very well https://github.com/felipetavares/dirac