Perhaps Jed Donnelley first wrote about some of these ideas. I don’t recall that his paper discussed encryption as that was considered an orthogonal issue in the days of symmetric ciphers. CORBA uses many of these ideas as well.

Several major reasons for distribution:

• to limit the impact of network latency or bandwidth cost. (There may be people or things that are remote from each other, each of which require quick response. Some dinosaurs had a hind brain. It is speculated that this provided rapid reflexes in the rear.)
• to overcome the capacity limits of a particular capability technology, such as the requirement to fit in one 32 bit address space, or one physical memory system.
• To divide work so that organizations responsible for part of the job can control the hardware that executes their part.
• To provide continuous service despite hardware failures.
• To protect one part of the application from another when no one is trusted to operate the site with the entire application.
• To support diverse policies for allocation of time and space.

The plan here is to provide distribution without modifying the implementation of most objects and without modifying the underlying capability mechanisms. (This scheme is harder to describe than to invent, but here goes.)

Remote messages are addressed via capabilities and may convey capabilities. If we are to maintain the advantages of capabilities we must ensure that messages are delivered remotely under the same rules that messages are delivered locally. Suppose that an object at site A holds a reference (capability) to an object at site B. Peeling away one abstraction we find that the reference is actually to a special object at A that can send a signal to a confederate at B who, in turn, will deliver a message that has the intended effect. By “signal” we mean an ordinary message over some communications channel such as a TCP circuit. We say “signal” to distinguish here from the messages between objects. For each object at B to which there is a remote reference at A, there is such a forwarder at A, to which the remote reference really refers. If a message includes a reference then the forwarder must encode the reference, for the bits within the reference will not serve at B. (Digression on Abstraction) Indeed the forwarder does not have access to the bits of the reference for the forwarder is an ordinary program. If the transmitted reference is to an object at B then that reference is recognized as actually a reference to a sibling forwarder at A. The siblings confer, the remote object identity is determined and the signal conveys that identity by a small integer index into a table of objects at B to which there are forwarders at A. The confederate delivers the real reference to the object at B to the recipient at B.

If the transmitted reference is to an object at A then a new forwarder is constructed at B and the message delivered at B has a reference to that new forwarder.

To present the essential ideas we have glossed over several important issues in the above description. We expand here:

• We assume that the code that arranges this distribution is itself subject to capability discipline. What capabilities are required to do that job?
  • Recognizing Siblings
  • Sending Bits on Wires; better; for Keykos
• Protocols to identify remote objects
• Communications Security and Authenticity
• Object Reference Transport Protocol
• Layering
• Concurrent Distribution Services
• Bootstrapping
• More than two Sites (My current recommendation)
• Management of Distribution
• Distribution with Confinement
• Mark Miller’s Distribution with Confinement
• For the logic of Pluribus, the wire protocols for capabilities in E, see references under “Pluribus Protocol” in ELib: Local and Remote