"Distributed object programming": Yes, CapTP allows you to program across networks with the level of convenience as if you were programming against *local objects*.
(Throw out your assumptions of "objects" as OOP, this can be functional; @spritelyproject's is)
Well, 250 lines for the protocol, a mere 300 lines more for the GUI: https://dustycloud.org/blog/spritely-goblins-v0.7-released/
And it was *easy* for me to think about the security properties... because I was just thinking about how the *program* worked.
That means less time spent on "bespoke APIs".
You may have also even used a variant of CapTP: Cap'N Proto is a kind of CapTP, and many of its users don't know.
We hope to standardize this variant of CapTP in @spritelyproject and be interoperable with @firstname.lastname@example.org even though we use Scheme and they use JS. Language-agnostic!
So what now? I just implemented the last two hard pieces in @spritelyproject's CapTP: "handoffs" and "shortening/unwrapping" of object references that come home, which honestly is extra technical details that aren't important to go into here.
So what's next?
First, I need to clean things up. Then I need to do a writeup of how things currently work in our implementation. Then @spritelyproject and Agoric can talk more about how to get our implementations to align. That process is going to take quite a while but now it can start.
@cwebber one big aspect you haven't mentioned is that CapTP is *asynchronous* (there can be many outgoing questions at the same time, and also there are promises that asynchronously resolve to capabilities). And if I understand it right, CapTP also allows for pipelining calls (sending a message to a yet unresolved promise).
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!