Hey, thanks for looking at SwingSet!
So the short answer is no, we don’t yet have a solo-to-solo communication pathway built yet (an equivalent of VatTP). We prioritized the solo-to-chain case for a hackathon-driven sprint back in June/July, and we’re in the process of a chain-to-chain pathway (using IBC) now. That might help with the solo-to-solo case too, but as you can imagine it looks different.
SwingSet is effectively a library for building “SwingSet Machines” (we’re in the market for better terminology, sometimes we call these “SwingSets”). You write a host program that links against the SwingSet library, giving it a way to save its persistent state, and you configure it with a set of initial (“genesis”) vats. The SwingSet Machine contains a kernel and a bunch of vats, and the usual run-queue and c-lists and stuff. Your host program gets back a “controller” object, whose primary API is controller.run(), which delivers messages from the run-queue into Vat-side objects until the queue is empty. We call this cycle a “Crank” (each “Turn” is a single message delivery, including resolved Promises that fire a then callback, so the “Crank” is complete when all pending Turns have finished: imagine turning the crank on a hand-operated machine until it stops).
To do more than a basic one-shot test, you need a way to add more messages to the run-queue after startup (in response to inbound network traffic). And to do anything interesting, the machine needs a way to exfiltrate messages. Both are managed with “Devices”, which are configured at the same time as the set of genesis vats. Devices can be given endowments that sit outside the kernel.
The main one to look at is the “Mailbox Device”. At the end of each Crank, you (in the host program) can ask the Mailbox for the outbound messages that need to be delivered to some named peer Machine. This also has the inbound ACK high-watermark number that needs to be delivered to that same Machine. You, in the host, are responsible for taking that bundle of JSON-serializable data and dropping it into the Mailbox of the appropriate remote Machine (including protecting its confidentiality, and providing integrity and authentication). When we build a new VatTP, it might look like a signed/encrypted datagram pipe to carry these Mailbox messages, bound to some sort of public key.
So basically the host application is responsible for IBC or P2P or whatever mechanism is used to get those messages from one machine to another. Neither the SwingSet kernel nor its devices speak directly to a network (which also helps with determinism/checkpointing, and avoiding what MarkM calls “hangover inconsistency”: we don’t release any messages until both the kernel and the mailbox state has been checkpointed).
hope that helps!
-Brian
