Also I don't know what the rush is to get a shiny new Rust implementation out asap that you need to vibe code the entire thing.

The Github stars couldn't be that serious.

Also the disclaimer at the end "Built with <3 in Rust. Ready for production use.";

Ready for production use is a strong strong claim when the entire thing is vibe-coded.

But would you mind renaming the packages to make it clear they aren't official, before too many people depend on them? Prefix with your name or "currentspace" or something?

I'd just hate for it to be a big mess later if we ever decide to release an official implementation (and if it's not based on yours).

I mentioned in the README that I leaned heavily on Claude Opus for the port. One of the biggest challenges was tamping down its default “everything is production-ready in a week” optimism. That said, I also discovered along the way which guardrails worked and which didn’t for guiding it toward a compliant implementation. It was good learning, and honestly, fun.

I’m genuinely interested in the Cap’n Web protocol. Writing this in Rust gave me a much clearer sense of where I would and wouldn’t use it. Credit to the Cloudflare team for defining the protocol and shipping a solid reference implementation, this wouldn’t have been possible otherwise.

A good example of why a second client (even one bootstrapped with AI) is useful: in implementation I ran into a spec ambiguity around array escaping (documented here: https://github.com/cloudflare/capnweb/issues/68 ). My initial Rust serializer emitted unescaped arrays at lower levels, and I even patched the TS reference to accept them. In the end, escaping arrays at all levels turned out to be the cleaner and more consistent approach, so I’ve recommended that clarification in the issue.

On naming: fair point about possible confusion with Cap’n Proto. If the Cloudflare team ever wants the crate names for an official Rust impl, they’re theirs. If there’s interest in pushing this to production ready quality, I’d also be glad to put in the work.

Thanks again for the constructive input. Happy to dive into technical details if folks are curious.

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 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?

mmm delicious slop may i have more please sir

But I guess this is just to be expected from AI slop.

I'd love to see (might try to add on) an optional type layer: define contracts as json schema or JTD or something? Does something like this already exist - maybe you could use protobufs ontop of this? Would be nice to make it so that you didn't need to share types between client / server out of band, something like an openapi spec allows all clients (not just those you are in control of) to have types!