Spritely is getting to a more serious state, and the Spritely Goblins layer is now implementing CapTP (still a few things to be done, but I think it's maybe at feature-parity with Agoric's implementation... a little bit ahead actually because we now have distributed acyclic garbage collection). Of course, that couldn't have happened without the wonderful help of folks at Agoric and on the cap-talk list who answered many questions for me.

Now the question is, can we get our CapTP implementations to interop? Obviously I'm not the only one that thinks it's a good idea.

So let's talk about what's different so far, of substance and non-substance.

Non-substantial things to eventually address:

• We don't use the same serialization format. Not a big deal, this is easy enough to converge on the same thing. I think we can both flesh out our implementations and find out our needs for the moment; neither of us is yet using the serialization format that we want long-term so it's easy enough to both switch later to something shared.
• Agoric's CapTP sees Vats as the fundamental barrier between connections and Goblins' sees Machines as the barrier. However, this might also not matter because really either can be perceived of as "the name that holds many objects that you're talking to", and you can't really tell whether or not its one or several event loops at this point.
• Making sure that all our operations look the same

Of medium substance:

• Making sure we have the same scalars.
• Goblins' CapTP provides an open world "extension type type" and I think that's a good idea for Agoric to have too.
• Should method names be symbols or strings? It's symbols conventionally in Goblins. I think that's the right call, especially because...
• Goblins is providing an optimization where symbols can be shortened and cached for a session. One side can say "I'm assigning this symbol to integer N", not unlike "I'm exporting this promise to integer N". This can reduce message sizes significantly.

Of major substance:

• AFAICT, Agoric's CapTP has no notion of a "session" ever breaking because it's assumed that store and forward mostly solves this. However a) Goblins needs to support low-latency, non-store-and-forward connection for some game purposes (though we want to support store and forward as well) and those will of course break and b) I think even store and forward sessions can end up in an irreconcilable state; if Alice believes the last message she received from Bob was 3, but Bob's machine goes up in flames and is restored from a backup with 2, and there are no records of 3 sitting around to be shared back to Bob again because they weren't held onto or GC'ed or whatever, then there's no way for those two to talk any more and a new session must be established anyway.
• For that matter, Goblins needs to correctly handle session disconnects too, heh
• Both of us need to implement handoff tables
• Both of us want to implement certificate chains, so we should examine a shared format

The biggest one:

• In Goblins's world, lambda is the ultimate. Any actor is merely providing a method handler as a procedure. Method dispatch is one particular kind of method that dispatches to a sub-procedure based on the first argument, but it's not fundamental. Therefore in Goblins, there is only one kind of message send, <-, and Lambda is the Ultimate. In Agoric's world, there are multiple kinds afaict: one for invoking methods, one for invoking procedures, one for fetching attributes (or are they called properties? I forget what term is used). Additionally, Agoric's implementation has a very nice feature where some kinds of scalars can also be indexed against to retrieve by numerical or string keys in a promise pipelining system, and Goblins doesn't provide this yet.

I have a suggestion on how to solve this last one taking good ideas for both but it's worth making a separate post on this issue for that since this is already long. :)

Thankfully, our worlds are made easier by both of us keeping the CapTP layer separate from what's traditionally called the VatTP layer (confusing name imo, but not a big deal... I like MachineTP better for multiple reasons but we can talk about that later.)

Okay... so I think that lays out the scope of stuff to think about for interoperability. Let's plan on getting our stuff talking!