4 ms·

I love Cap'n Proto, but I wish it came with more advice on how to use it as part of a full solution. For example, if you're looking for service registration an

by ipsin 12y ago

I love Cap'n Proto, but I wish it came with more advice on how to use it as part of a full solution. For example, if you're looking for service registration and discovery, authentication or encryption, the answer seems to be "do something else, then add Cap'n Proto". I realize it probably sounds like I'm asking for hand-holding, but I'm curious how people are using it as part of this nutritious breakfast... er, I mean, back-end infrastructure.

kentonv 12y ago
It's true, Cap'n Proto is not a complete solution yet, and in particular there's a lot of work to be done on RPC. Currently RPC can operate over any arbitrary two-way byte stream you give it (e.g. a TCP connection), but if you want encryption then it's up to you to provide a stream that does encryption. I'd like to build more of this into the system. In fact, it's probably a requirement for sandstorm.io (my main project). It'll take time, though. FWIW, Cap'n Proto RPC is working great in Sandstorm as a way for sandboxed processes to communicate with the supervisor. This is entirely IPC so far, so encryption is not needed.
- stouset 12y ago
  It seems to me like Cap'n Proto is better off without any inherent encryption layer. Let the user be responsible for setting up a two-way stream with their own security requirements. There's no reason Cap'n Proto should duplicate the efforts of TLS.
  - kentonv 12y ago
    Maybe. But Cap'n Proto implements a capability-based model which is more web-of-trust than PKI, so arguably a lot of what's in TLS (and a lot of what makes TLS complicated) is irrelevant to it. I agree that people who actually want traditional PKI should use TLS; we're certainly not going to reinvent that. But there's an opportunity to do something much simpler. There's also the issue that Cap'n Proto wants to implement a distributed capability fabric in which machine A may have a capability to an object on machine B and may send that capability to machine C, after which machine C should form a direct connection to machine B in order to make calls on that capability. How to accomplish this (without PKI) is well-known, but it may prove convoluted to build it with TLS as the basic building block. I have to do more research, though.
uuilly 12y ago
This sort of thing is great for messages in real time systems or robotic systems where firing up a JSON parser / serializer just isn't an option. We use something similar in our system but I've had my eye on Cap'n Proto for a while...

by ipsin 12y ago

kentonv 12y ago

It's true, Cap'n Proto is not a complete solution yet, and in particular there's a lot of work to be done on RPC. Currently RPC can operate over any arbitrary two-way byte stream you give it (e.g. a TCP connection), but if you want encryption then it's up to you to provide a stream that does encryption. I'd like to build more of this into the system. In fact, it's probably a requirement for sandstorm.io (my main project). It'll take time, though. FWIW, Cap'n Proto RPC is working great in Sandstorm as a way for sandboxed processes to communicate with the supervisor. This is entirely IPC so far, so encryption is not needed.

stouset 12y ago
It seems to me like Cap'n Proto is better off without any inherent encryption layer. Let the user be responsible for setting up a two-way stream with their own security requirements. There's no reason Cap'n Proto should duplicate the efforts of TLS.
- kentonv 12y ago
  Maybe. But Cap'n Proto implements a capability-based model which is more web-of-trust than PKI, so arguably a lot of what's in TLS (and a lot of what makes TLS complicated) is irrelevant to it. I agree that people who actually want traditional PKI should use TLS; we're certainly not going to reinvent that. But there's an opportunity to do something much simpler. There's also the issue that Cap'n Proto wants to implement a distributed capability fabric in which machine A may have a capability to an object on machine B and may send that capability to machine C, after which machine C should form a direct connection to machine B in order to make calls on that capability. How to accomplish this (without PKI) is well-known, but it may prove convoluted to build it with TLS as the basic building block. I have to do more research, though.

uuilly 12y ago

This sort of thing is great for messages in real time systems or robotic systems where firing up a JSON parser / serializer just isn't an option. We use something similar in our system but I've had my eye on Cap'n Proto for a while...