Canopy: C++ RPC With Coroutines and a

The history of RPC is basically a history of people solving the same problem with increasing sophistication and then watching the solution become someone else's problem. CORBA was elegant in theory and a bureaucratic nightmare in practice. gRPC solved a lot of what CORBA got wrong and then handed you a different set of tradeoffs. Every generation of distributed systems engineers eventually decides the existing tools don't quite fit and builds something closer to what they actually need.

Edward Boggis-Rolfe is somewhere in that tradition. At C++Online 2026, he gave a lightning talk on Canopy—an RPC library he's been building that manages the lifetime of remote objects through RAII, supports coroutines, handles multiple serialization formats, and runs across multiple transport layers. His entry point is a frustration that's genuinely familiar to anyone who's worked in constrained or secure environments: "Most people are basically working on blocking calls and it doesn't scale well, especially when my background is in secure confidential environments where most stuff is using blocking IO and a limited number of threads."

That's not a hypothetical gripe. Blocking RPC in a system with a thread budget is a real architectural ceiling, and it's one the C++ ecosystem has been slow to address cleanly. So the question is whether Canopy is filling a real gap or reconstructing a wheel that already exists in several forms.

What Canopy Actually Does

The core of Boggis-Rolfe's design is an object-oriented RPC model that traces its intellectual lineage to COM—the 1990s Microsoft Component Object Model—and to CORBA. You define interfaces using an IDL (Interface Definition Language) parser he says he wrote about 30 years ago. Those interfaces describe what a remote object can do: what parameters go in, what comes back. The system then handles marshalling data across whatever transport you're using—TCP, IPC, or others—and can serialize in JSON, protobuf, or a format Boggis-Rolfe refers to as "bison."

What's genuinely new here is how Canopy handles the async story. Traditional RPC blocks a thread until a response arrives. Canopy lets you use C++20 coroutines instead—so your calling code suspends at the await point and the thread stays free. He's also added what he calls "one-way calls," annotated with a post attribute, for situations where you're sending fire-and-forget data—a streaming LLM response, for instance—and don't need to block waiting for an acknowledgment.

The other notable piece is what he calls "optimistic pointers"—callable weak pointers that maintain a reference to a remote interface without keeping the remote service alive or dying when the local reference goes out of scope. "When your weak pointer goes out of scope, it doesn't kill the remote service. It's just there." The use case he describes is exactly the kind of scenario that breaks naive reference-counting in distributed systems: long-lived services like databases or LLMs that should outlive any individual caller's reference to them.

On top of that, Canopy supports multiple hops across transports—you can route a call from one machine into a confidential enclave, for instance—and has a back-channel mechanism for passing attestation values, telemetry keys, or certificates alongside the actual payload. For someone working in trusted execution environments, that's not a nice-to-have. It's the whole problem.

Where It Sits in the Ecosystem

The developers in Boggis-Rolfe's audience already know gRPC, Boost.Asio, and Cap'n Proto. They've probably spent time with Apache Thrift or ZeroMQ. So where does Canopy actually fit?

gRPC gives you a mature, Google-backed RPC framework with strong protobuf integration and a real contributor ecosystem. What it doesn't give you is RAII-managed remote object lifetimes, first-class coroutine support baked into the object model, or the kind of multi-transport, multi-hop flexibility Boggis-Rolfe is describing. Cap'n Proto is fast and clever but it's not an RPC object system in the COM-lineage sense. Boost.Asio handles async I/O beautifully but it's infrastructure, not an opinionated RPC layer.

Canopy's actual differentiator appears to be the combination: RAII semantics extended to remote objects, coroutine-native async without bolting it on after the fact, and a design that explicitly accommodates confidential computing environments where your transport might not be TCP and your OS might not be directly accessible. That's a genuinely underserved corner of the ecosystem. Whether it's underserved because the problem is rare or because it's hard to solve—and whether Canopy solves it durably—is the open question.

Boggis-Rolfe acknowledges the library is in "the final stages of beta" and has been in active development for a few months. His slides were already out of date by the time he was presenting them. That's not a knock—it suggests active iteration. But it also means this is a library where the stability picture is still forming.

The MCP Angle, and Why It Matters

Here's what I find most interesting in an eight-minute talk that's officially about coroutines: Boggis-Rolfe mentions that Canopy's remote reflection capability lets you expose defined interfaces to external dispatch protocols—including Model Context Protocol.

MCP is worth being precise about here. It's Anthropic's protocol for letting LLM agents call external tools and services, and it's moved from early experiment to something that multiple AI toolchains are converging on. Whether that convergence represents genuine production adoption or an AI-hype tailwind that could reverse is a legitimate question. But the directionality is real: there's actual demand for well-typed, structured RPC at the boundary between AI inference and backend services, and that demand is currently being served mostly by thin HTTP wrappers and a lot of prayer.

What Boggis-Rolfe is building—if it holds up—is a lower-level, more principled foundation for exactly that boundary. A system that can manage remote object lifetimes, handle streaming LLM responses via one-way calls, pass attestation values through a back channel, and bridge into a confidential enclave is actually a fairly precise description of what you'd want when an AI agent needs to call production infrastructure in a security-conscious environment. The convergence of classical distributed systems tooling with AI infrastructure isn't a niche intersection. It's increasingly where the hard problems are.

The Community Question Nobody Asked

Here's the thing I keep coming back to as the person who covers this beat: Canopy, as far as the talk reveals, is one person's library. Boggis-Rolfe is clearly deep in it—thirty years of context, an IDL parser he built himself, a confidential computing background that shaped every design decision. That expertise is the library's greatest strength and its clearest structural vulnerability.

The C++ ecosystem is littered with genuinely excellent one-person RPC and serialization libraries that solved real problems and then quietly stagnated when life intervened, or thrived only because a corporate sponsor needed them to. The talk doesn't surface any information about where Canopy's code lives publicly, whether there's an issue tracker open to contributors, or whether Boggis-Rolfe is looking to build a contributor community or ship a polished personal tool. Those aren't small questions. A library that handles serialization format negotiation, transport abstraction, trusted execution environments, and now MCP integration is not a weekend project that one person can keep current indefinitely.

The language-agnostic ambitions he mentions make this more acute, not less. COM and CORBA both required enormous institutional machinery to maintain their cross-language contracts. gRPC has Google. What does Canopy have?

I don't ask that to dismiss the work—the technical thinking here is serious, and the problem space is real. I ask it because for any library touching the intersection of confidential computing and AI infrastructure, the sustainability question is the technical question. Code that production systems depend on needs a maintainer story, not just an architecture story.

Boggis-Rolfe closed his lightning talk with a self-deprecating "I need more practice" and a pointer to a fuller session the following day. The rush of an eight-minute slot probably wasn't the place to lay out a governance model. But if Canopy is going to be more than one engineer's well-built personal toolkit, that conversation needs to happen soon—before the first wave of interested developers shows up, finds no CONTRIBUTING.md, and wanders off to gRPC anyway.

Dev Kapoor is Buzzrag's Open Source and Developer Communities Correspondent.