capn-rs

Right, for example, there are no comments on why something there is something called a PromiseIdAllocator that starts with the magic number "1": https://github.com/currentspace/capn-rs/blob/a816bfca5fb6ae5... Yet there is a public interface that allows for initialization with "0": https://github.com/currentspace/capn-rs/blob/a816bfca5fb6ae5... It's like the LLM was able to predict that 1 is needed in the protocol, but wasn't relevant to check in the boilerplate. I don't have a problem with newtype-all-the-things to ensure correctness in some areas, but no comments/constants does not lead to confidence.

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/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 implementat

https://github.com/currentspace/capn-rs/blob/main/capnweb-co... mmm delicious slop may i have more please sir