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 via this gist if you wish access or have any questions. Thank you!

@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

I've ported both libaom (video decoder, still encoder, latest release as of today) and svt-av1 (full encoder for still and video), with the svt-av1-hdr enhancements released a few weeks ago. https://github.com/imazen/zenav1-svt and https://github.com/imazen/zenav1-aom. They're bit-exact for almost the entire configuration surface when in parity mode (although I've made additional opt-in optimizations). I also have the avif decoder/encoder muxer side. I also rewrote rav1d (rav1d-safe) as the fastest pure-safe Rust av1 decoder.

These are all tested with vast data sets, and I use IQA and video quality metrics (I ported vmaf and cvvdp to pure rust as well) to ensure they are all at the pareto front across all implementations I'm aware of.

I intent to maintain these for many years in the future, as it's part of my image library that has a commercial support system (I've been doing that since 2010).

Security-wise, these are all forbid_unsafe, and use archmage (it's like fearless_simd) to get either faster than the C implementations or within 20% ish.

I think the av1 and avif crate names would be ideal for these. If I don't hear back I'll proceed publishing them under zenav1-*, but ideally I'd like to not have deprecated/yanked crates later due to a rename. Thanks!