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.