Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocap bill of rights #17

Open
dckc opened this issue Sep 25, 2020 · 2 comments
Open

ocap bill of rights #17

dckc opened this issue Sep 25, 2020 · 2 comments

Comments

@dckc
Copy link
Owner

dckc commented Sep 25, 2020

https://lobste.rs/s/fnfzbt/object_capability_model#c_uolfnw

@dckc
Copy link
Owner Author

dckc commented Nov 22, 2021

Encapsulation of information ensures that one object cannot directly read or tamper with the contents of another; communication enables objects to exchange information by mutual consent. The encapsulation and communication of access ensures that communication rights are similarly controlled and transferable only by mutual consent.
-- Miller & Drexler, 1988

@dckc
Copy link
Owner Author

dckc commented Nov 22, 2021

full text for archiving:

The biggest distinction between object-capability models and other capability models is that an object has rights. This is so intertwined with the history of object-capability discipline that the most well-known ocap language, E, put “rights” in their URL, erights.org.

An object has a right to keep its closure of object references, its own capabilities, private from other objects. This right to privacy means that an object communicates only by passing messages, and that objects appear “unityped” or otherwise common since they all share a single unified messaging API. We can actually enumerate a series of corresponding rights:

  • Right to Privacy: An object’s closure is effectively sealed (as if by a brand sealer), and the unsealers are closely-held only by the object itself and a few runtime objects, particularly the interpreter and debugger.
  • Right to Anonymity: An object has no inherent name. An object is known only by its identity, and shall only be compared by others by consenting and conforming to a comparison API.
  • Right to Be Forgotten: If no references to an object are held by anybody else, and there are no more messages left to deliver to the object, then the object might as well not exist, and has the right to be garbage-collected or otherwise permanently abandoned; no more references should be forged to it.
  • Right to Safe Computation: Even if every single name in the “safe” scope, which is typically available, is taken away, and even if all of the syntactic sugar is removed, objects still can create some primitive values, like functions and integers, and do basic arithmetic. Languages vary greatly in how much power is granted; Pola is complete for P, Monte’s kernel language is (Turing-)complete for RE, and ActorScript’s author claims that their technique is even more powerful, although I still would like to see them implement it.

Specific to Monte (which I work on) and other members of the E family are some additional rights:

  • Right to Due Process, or “no stale stack frames”: Calling an object immediately, by passing it a message and then waiting for the runtime to complete evaluation, is non-blocking. Only infinite loops (due to Turing-completeness) can prevent a call from returning, and only that or a thrown exception can prevent control from returning.
  • Miranda rights: When an object is created, if its script is missing some essential methods for existing in object-society, then they will be provided automatically. These are known as Miranda methods. In addition, some keyword arguments are added to every passed message. This Miranda protocol facilitates error propagation, pretty-printing, the opaque and uniform object API, and more.

Objects have rights because objects do not have to trust each other in order to compute, only pass messages between each other.
-- Corbin 2018-11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant