What is OCAP?
A system including programs, that hold caps, invoke them by sending messages addressed by caps. Messages are explicitly built by the sending code and include data and other held caps. Programs receive message, so sent, do with the data as they please, and accumulate the received caps among those they hold, remembering whence they came. There is a general vague presumption that all cause and effect is via capabilities.

New objects may be had by supplying a program, and in return receiving new caps with which to send messages to that program.

To achieve your plans you add objects that do your bidding and rely on some objects already there, caps to which you are given. The game is to minimize the total size of the programs you must rely on to achieve your ends. Perhaps ‘total size’ is not the right metric; credibility of the authors of the programs you rely on comes first. Size of specification of those programs may be even more significant.

We claim that cap discipline vastly reduces the size of the code that you must rely upon for your plans. But your code generally relies on an operating system and its kernel. Thus the cap kernel.

Cap ideas have blossomed in several worlds already with much cross pollination.

My plan today is to talk about the technology closest to the silicon, not because it is important, but because it is necessary for the other OCAP goals. Further, there are bridges to be built between these domains for architecture ideas to flow.

How is it different? —How is it the same?
Synergy in some guise
How memory mapping (MMU) is much like memory descriptors
Anecdote on Keykos performance and limitations on what can be learned there