What are Capabilities

Only objects hold caps and caps designate objects.
Each object obeys its own program.
Objects also hold RW access to their data.
Those programs cause the object to send messages including some of their data and caps, via one of their caps.
Messages sent via caps are delivered to obs that the cap designates, to be interpreted by the programs of those obs. (Is a node an ob?)

Caps and Data are Both Located by Program Supplied Addresses

Programs know their caps by local addresses, just like their data. To use the authority of a capability it holds, the program must specify its address, just as it must specify the address of data that it uses. The system doesn’t go searching for some excuse (cap) to let you do something!

Obs have Behavior and State

Said otherwise: An object is comprised of behavior and state. The behavior comes from the program that it obeys (machine code in the case of cap kernels and some language in language based systems.) The state is coded in the current state of the program’s data, together with state of the objects designated by the held capabilities. Two objects may share behavior, but not state. (Quibble)

If we deconstruct an object we discover that it accesses its program, data and caps via caps.

New Obs

Contributors to the system, including the bad guys, even other obs, are free to create objects that obey programs that they write. Security and integrity stems from who holds what caps.

Whither Caps (& Obs)

There are at least these levels at which one should apply capability ideas: “Platform” means OS or other sort of system that hosts software applications. Language solutions have pretty much ignored some of the necessary elements. Platform solutions operate on a coarse grain that solves many important problems, but not all. These levels should be made seamless, or there should be places to stand where the seams are invisible.