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

"Mutually suspicious networks": there's no assumption that trust exists on server-boundaries... CapTP is built to allow collaboration *without* full trust.

Curiously, this approach allows for *increased* collaboration and building more trust; collaboration is more consensual.

Just to clarify: I feel safer knowing I do not need to trust all people equally and with the same things in my own life. I try not to base trust on boundaries of membership of nationality or household.

In P2P systems this is extra important if making new nodes is trivial.

"Combined with object capability style of programming": this combination is where the power really comes out. *Safe, cooperative interaction* is very *easy* in the ocap style: it turns out capability flows can be encoded as normal programming: argument passing and scope!

CapTP is designed to collaborate with this, and it means building secure systems is *easier than ever*: the protocol takes care of most security concerns, and programmers are left to think about the semantics of passing around variable references, which is *easy* to reason about.

This also means that writing distributed "protocols" often turns out to be a trivial operation because CapTP has already done most of the work.

I did a 250 line client/server p2p chat "protocol", designed it locally first; it "automatically" worked over the network due to CapTP

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

Before I get any further on the "cool details": I want to emphasize that CapTP is not a @spritelyproject
invention. Mark S. Miller and many others helped me understand the design, which goes back 20 years in the E language: http://erights.org

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 @agoric@twitter.com even though we use Scheme and they use JS. Language-agnostic!

Back to the cool features. CapTP is very *efficient*: you may have used ocap systems that have huge certificates or URIs. Nope, in CapTP a shared capability is merely a *bidirectional integer assignment* between the importer and exporter! (But users need not be aware of this.)

CapTP also has distributed acyclic garbage collection. That means that two servers can collaborate to say "oh yeah, thanks for giving me that object, but you don't need to hold onto it any more on my behalf." Wow!!!

CapTP also has "promise pipelining", which reduces round trips. I can send a message to a remote car factory and ask it to drive the car once it makes it, even before I've been told the car is made!

Languages which support it can make this look "natural" too!

So all in all, this reduces the amount of work for rich, networked collaborations with safety properties we can reason about from something which only protocol hyper-experts are deemed worthy to consider, to something that us mere mortals can think about.

You just write code!

Now the state of things: Agoric and @spritelyproject both want to implement the same CapTP (we aren't yet). @spritelyproject is a bit further ahead right now, but only got there with the help of folks at Agoric, so we really are working together!

(The reason @spritelyproject is further ahead is that Agoric is doing the hard work of helping the Javascript community get the features necessary to build this dream (important!); @spritelyproject started off on a more obscure foundation that already had all the needed pieces.)

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.

The next thing to do is to start building demos. Longform textual explanations are good and well, but "seeing is believing". CapTP is only exciting because it's a powerful *foundation* for what's to come. Time to give people a taste of the future... seeing is believing.

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