I think Protobuf fundamentally can't achieve zero-copy parsing without changing the underlying encoding. That said, zero-copy parsing only provides a significan

I think Protobuf fundamentally can't achieve zero-copy parsing without changing the underlying encoding. That said, zero-copy parsing only provides a significant real-world benefit in certain use cases. For the use case of RPC over a network -- especially over the internet -- zero-copy parsing has minimal benefit. The places where zero-copy parsing can be a big win are when it means you can mmap() a very large file, or for IPC in shared memory. On the other hand, Promise Pipelining -- and, more generally, object-capability RPC -- could definitely be added to gRPC. In fact, the very first iteration of Cap'n Proto was a Protobuf-based RPC system that used the same service definition syntax that gRPC now uses. "Cap'n Proto" at the time meant "capabilities and protobuf". (That version of the project was short-lived and shares no code at all with the current Cap'n Proto.) However, I don't think gRPC is likely to add ocaps unless and until the model proves itself by gaining wide popularity elsewhere. It doesn't make sense for gRPC to take the risk of adding a big, new, experimental feature which they'll be forced to support forever when the demand hasn't been proven yet. Ocaps are gaining a lot of popularity lately (with major new tech like Fuschia and WASI being capability-based) but I think there's still further to go before it would make sense for gRPC to adopt it.