What Synergy does Cap Distribution need?

We consider the wire protocol for I find it simpler. I may be surprised that other distribution protocols need different synergy. The link above does not say much about the logic of T but we say more here. When, in one cap system, a program invokes an object on another system: There will be another version of T that we call T' running at the other end of the wire. They will be configured the same and we describe T. T holds a “Key Indexed Directory” (KID which is not primitive but employs a rare primitive which it promises not to abuse.) The KID is a map from keys to small integers. T also employs a “super node” which maps from integers to keys. The KID and super node are inverses of each other.

If the message of the invocation includes caps then the following must happen for each such cap X:

In either case T has a small integer, n, which is sent over the wire to identify the cap within the transmitted message to T'. n is accompanied by a bit indicating whether X is new to T. If X was new to T then T' creates a new surrogate for X. If X was old to T then T' uses n to construct a key to the extant far surrogate for X.

I will probably find important bugs in the above story but enough for now.

Among WeakMap designs the KID is minimal. It only recollects integers and in fact does not store keys.


The KID needs something that obeys the classic axioms for equality from predicate logic. Left-equals doesn’t provide that. T must distribute access to even buggy objects.