-
Notifications
You must be signed in to change notification settings - Fork 214
OCap Discipline
In brief:
-
modules should not export powerful objects (for example, objects that close over
fs
orprocess.env
) (#2160) -
program scripts are indicated with
#!/usr/bin/env node
at the top (and +x file permissions). They are free to import all the authority they need and then delegate it. -
test scripts are named
test-*.js
. Note that tests don't export anything.
A key to cooperation without vulnerability is object capability discipline, which consists of:
-
Memory safety and encapsulation: There is no way to get a reference to an object except by creating one or being given one at creation or via a message; no casting integers to pointers, for example.
From outside an object, there is no way to access the internal state of the object without the object’s consent (where consent is expressed by responding to messages). -
Primitive effects only via references The only way an object can affect the world outside itself is via references to other objects. All primitives for interacting with the external world are embodied by primitive objects and anything globally accessible is immutable data. There is no
open(filename)
function in the global namespace, nor can such a function be imported -- converting a string to file access is much like converting an integer to a pointer.
Object Capabilities are often abbreviated as OCaps; hence OCap discipline.
On the Agoric platform, OCap discipline is enforced on contracts.
While JavaScript platforms (browsers, node) don't enforce OCap discipline in general, SES lets us layer it on top.
- 2006-05: Miller, M.S.: Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, Baltimore, Maryland, USA
- See also a history of E’s ideas.
See also;
This wiki is for developing agoric-sdk. For help using Agoric SDK, see https://docs.agoric.com/ and https://agoric-sdk.pages.dev/