Regarding the concept, it's cool to see you using LLMs to quickly generate protocol versions. But asking the community to review an AI-generated implementation

Regarding the concept, it's cool to see you using LLMs to quickly generate protocol versions. But asking the community to review an AI-generated implementation week-old announced protocol, is more or less putting the recently coined-term AI "workslop" upon others. It doesn't really matter if it happens to be a good implementation or not. There are two main issues I can think of right now: 1) Work going into the protocol is only useful for your implementation of it. The capnweb-core crate depends on the tokio runtime, and parts of the protocol/definitions are in the client crate: https://github.com/currentspace/capn-rs/blob/a816bfca5fb6ae5ce957c3db849bf3842447bd19/capnweb-client/src/client.rs#L82-L86 https://github.com/currentspace/capn-rs/blob/a816bfca5fb6ae5... What if someone wants to leverage work into the core parts of the protocol to use a different runtime or no-std? 2) The project has namespace squatted/swiped the best name for the official implementation of the project. I understand Rust/Crates-IO allows for this free-for-all, but isn't it entirely possible that Cloudflare already has Rust crates for this that they might open source? Or if someone else wants to make a competing implementation? Maybe it's just me, but I like to put my organization prefix on all my crates in the event I ever open source any of them. Would you offer to transfer the crate names to Cloudflare if they were going to offer an implementation -- just like what happened with protobuf/Google?