Show HN: Cap'n-rs – Rust implementation of Cloudflare's Cap'n Web protocol

(github.com)

51 points by brian_meek 3 days ago

35 comments

View on Hacker News

Last week Cloudflare released Cap'n Web [1], a schema-free capability-based RPC protocol. I built capn-rs this week - a Rust implementation with full wire protocol compatibility. Links:

GitHub: https://github.com/currentspace/capn-rs Crates: https://crates.io/crates/capnweb-server API docs: https://docs.rs/capnweb-server

What's working:

Wire compatibility verified via integration tests against TypeScript reference Multi-transport: HTTP batch, WebSocket, WebTransport (HTTP/3) Complete IL (intermediate language) expression evaluator Promise pipelining with dependency resolution Comprehensive test coverage

The interesting design challenge was mapping Cap'n Web's record-replay .map() semantics to Rust's type system while maintaining ergonomic APIs. Cap'n Web records operations on placeholder values to build execution plans - in Rust this became a clean builder pattern with type-level guarantees. Built this as an experiment with Claude Code for porting complex protocols. The AI handled mechanical translation well, but architectural decisions (especially around async/await patterns and lifetime management) required human judgment. This is early days - I'd especially appreciate feedback on API ergonomics and any edge cases I might have missed. Also happy to discuss the protocol design or the AI-assisted development experience.

[1] https://news.ycombinator.com/item?id=45332883

kentonv 3 days ago

Hey it's super-cool that you've implemented Cap'n Web in Rust! Nice!

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).

Reply View 1 reply
  • brian_meek 3 days ago

    Thanks for looking, and yes, I can rename it. Will do today. Also, thanks for the excellent protocol. In this entire "effort", I only found one ambiguity in it (and reported it in your repo). Everything about it was well defined and succinct. The pipelining is really useful.

    Reply View 0 replies
brian_meek 3 days ago

OP here. Thanks for all the thoughtful feedback, I really appreciate it.

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.

Reply View 2 replies
  • brian_meek 3 days ago

    I'm happy to make the name available to later implementations with committed resources, and I definitely welcome contributions to this implementation if you find it useful. This week I'm going to try building a for pet projects on it and will likely make some changes to improve this.

    Reply View 0 replies
  • dlahoda 3 days ago

    did you use lates claude release? did you ask codex to review and bug fix? what wat time spent promting, manual fixes and waiting for agent to finish work?

    Reply View 0 replies
no_circuit 3 days ago

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

Reply View 3 replies
h4ch1 3 days ago

"I built" more like claude-code built.

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.

Reply View 5 replies
  • mort96 3 days ago

    The two big signifiers that something is "ready for production use" are: 1) it has been successfully been used in production at some scale for a while, and 2) it has some commitment to API stability. A 1 week old project on version "0.1.0" is neither, whether vibe-coded or not.

    Reply View 2 replies
    • brian_meek 3 days ago

      OP here. I frankly stopped trying to add evals for the "ready for production" happiness Claude is trained to produce. I agree, not ready for production. I did though put a intention and effort into guarding against slop in implementation and tests. Sure I can still find it, but I believe the current state is solid enough to build on, and I will be doing so for some pet projects. I'll let you know what I find when using it in anger.

      Reply View 1 reply
      • mort96 3 days ago

        What do you mean by this?

        > I frankly stopped trying to add evals for the "ready for production" happiness Claude is trained to produce.

        It's your readme, no? Does Claude just go in and change it behind your back..? What's going on here, are you not in control of what you push to git?

        Moreover, what thought process makes you okay with lying in your readme just because the robot wanted you to?

        Reply View 0 replies
  • bryanlarsen 3 days ago

    Did you look at the code? There's probably AI slop in the unit tests or other ancillary code, but the API and core code show obvious signs of significant care and attention. I couldn't find evidence of the kind of slop Claude can create in rust in the 2 source files I looked at. Vibe-coded means not looking at the code, this is very obviously not that.

    Reply View 1 reply
    • brian_meek 3 days ago

      Thank you. Along the way in doing this I spent most of my effort in providing guard rails to eliminate or reduce slop. My goal was something I can use in other pet projects and maintain. I'm satisfied with the outcome, and appreciate you noticing it wasn't just yolo vibe coding.

      Reply View 0 replies
IshKebab 3 days ago

I would recommend not having an AI write your README. Even if you didn't use AI for coding at all and the code works perfectly, it really doesn't inspire confidence.

Reply View 8 replies
  • sandblast 3 days ago

    Well, most of commits have „brianathere and claude” as authors. Additionally, the style of comments in some of the files bears a strong resemblance to those typically generated by LLMs.

    Moreover, this whole thing has 7 stars on GitHub as of writing, and yet the bottom of README boldly claims „ready for production use”. For me, that overly confident approach discourages maybe even more.

    Reply View 0 replies
  • WD-42 3 days ago

    Yup the second I saw the wall of text paragraph with all the emojis I had a sinking feeling the entire thing could be a vibe coded mess. Too bad because the project seems cool.

    Reply View 3 replies
    • typpilol 3 days ago

      Makes me sad because I used to put a lot of effort into my readmes. Not insane amount of emojis but some and actually useful badges but not overkill. But in the end they always had nicely structured layouts etc..

      I feel like I have to make mine sloppier now to pass the AI smell test

      Reply View 2 replies
      • sandblast 3 days ago

        Maybe it was also your style that the LLMs learned from (and then pushed more towards the extreme). Oh the irony.

        Reply View 1 reply
  • adrian17 3 days ago

    The commit names look very weird too, feel more like marketing speak:

    > BREAKTHROUGH: Fix critical ID mismatch in Cap'n Web protocol

    > TIER 3 ULTIMATE: Extreme Stress Tests & Advanced Capability Composition

    > Achieve Cap'n Web protocol mastery with perfect capability composition (note: this exact commit name is repeated another time)

    The commit descriptions are even worse. If they’re so blatantly not written for anyone to read, why bother generating them at all?

    Reply View 2 replies
    • brian_meek 3 days ago

      OP here. :-) (feel like I should put an emoji here). My focus as I "built" this was getting to a correct implementation, and putting in place guards and context to achieve that. As I moved through the process I added more and more ways to eval progress toward that. An area I didn't invest any of my effort in was commit messages, and some of them caused me to spit take as I saw them go by. I think this is something that can definitely be improved, and this conversation is fuel for thought on how to do this.

      Reply View 0 replies
q3k 3 days ago

https://github.com/currentspace/capn-rs/blob/main/capnweb-co...

mmm delicious slop may i have more please sir

Reply View 2 replies
mort96 3 days ago

Okay the name is very unfortunate. "Cap'n-rs" sounds like it's gonna be a Rust implementation of Cap'n Proto, the much older and more widely used and more widely known serialization format.

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

Reply View 3 replies
  • monadoid 3 days ago

    This is someone's rust port of the new "cap'n web" protocol Kenton just released, which he's calling a spiritual sibling to cap'n proto (which he also built). This might be AI slop but this info is all in the OP, come on man!

    Reply View 2 replies
    • mort96 3 days ago

      I know all that already and none of it goes against what I said, so why the antagonistic tone?

      I do think that Kenton shares some of the blame by making their new JSON-based schemaless RPC system so similarly named to their old binary schema-based serialization format... I don't get the reasoning there. But that doesn't change what I said.

      Reply View 1 reply
      • monadoid 3 days ago

        Yeah fair enough, I guess the core of it might just be the similar names!

        Reply View 0 replies
monadoid 3 days ago

Despite everyone hating on the AI slop (I myself hate AI slop), I am excited about cap'n web and am jonesing to try it out in rust so I will take a look!

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!

Reply View 3 replies
  • mort96 3 days ago

    To be honest, I don't really understand the point of Cap'n Web.. it's a slightly better JSON-RPC I guess?

    I'm a fan of Cap'n Proto, but I don't understand how Cap'n Web is in any way related to it nor what makes it a big deal.

    Reply View 2 replies
    • nextaccountic 3 days ago

      The selling point is promise pipelining, being able to do many chained operations with a single api call

      This includes the freaky way they found to make this work with map

      Reply View 1 reply
      • brian_meek 3 days ago

        OP here, and yes, the chained operations are excellent. Having built this, and now using it some pet projects, that is the part I'm finding valuable.

        Reply View 0 replies