Re: Aha from the capabilities newbie

On Sep 16, 2014, at 0:09, John Carlson <[email protected]> wrote:

> I had the hardest time figuring out the object capability model, coming from UNIX and Java/C/C++, but I think I finally figured the model out by trying to map JSON onto a file system.  Minecraft might be thought of as almost the opposite of the object capability model, That is, ambient authority.

I regret to have to say that either you have greatly misunderstood capabilities, or you have not communicated your understanding clearly.

If you have a strong understanding of Unix, then there is a remarkably good example of object-capabilities built right into Unix: open files (file descriptors). They are referred to unforgeably (file descriptors being process-local), come in several different types and share a somewhat common interface, and can be come to be held by creation of a capability (pipe(), open(), etc.), by creation of a process (fork()), or by introduction (oddly, via unix domain sockets only).

Of course, file descriptors are not typically used in a capability fashion, but they are a working concrete example.


> Classes are objects.  Objects link to class scope items.  Objects may have methods which override the class methods.  Capabilities are granted on object methods—-at least.
> Object attribute names are filenames.
> Object attribute values are values or “files"
> Objects are folders.
> Array indexes are "filenames", or integer indexes into a stream, folder, image, window, window server or network of displays.
> One dimensional arrays are monoaural sounds or streams or c-list or machine code methods.
> Two dimensional arrays are folders, image files a snapshot of a window, or non-monoaural sounds
> I'm not sure the next three can be in a capability model.  What do you think?
> Three dimensional arrays are windows or video streams or a snapshot of a Minecraft world.
> ...

Everything you have described here seems to be about an object model. The capability principles, even object capabilities, have nothing to say about what kinds of objects shall exist; only about the nature of *references to* objects. Many types of capability and object-capability systems are possible provided that they obey the "axioms".


> Unforgeable references are links pointing somewhere in the filesystem, which makes the "JSON" a DAG.

Capability systems generally permit a general directed graph, not an acyclic one.


> Capabilities are integers which assign an authority (read, write, execute, put, get, create, remove, post, delete, head, grant, revoke)  to a value.

No, an object capability is not an integer. A c-list index (or a file descriptor) may designate a capability held by a process, but it is not itself the capability. For example, multiple processes may hold the same capability but refer to it using different indices.

(Sufficiently large and random integers may be employed as _sparse_ (cryptographic) capabilities, but that is another matter.)


> Here are my questions:

(I have not quoted questions which I could not give good answers to in light of the broad disagreement I describe above.)


> What are formal and actual parameters to execute and other authorities called?  Are these classes and objects as well?

Capabiliies do not require a specific model of invocation/execution. The only constraint is that the invocation mechanism be able to pass capabilities (_introduction_) as well as data.


> Would it be possible to have only REST authorities?

The exact question does not make sense to me, but I will comment on REST.

REST is a constraint on usage patterns of HTTP. Generally speaking, a REST system is more like a capability system than a system not designed with the constraints of REST. In particular:

1. REST specifies sending messages (HTTP requests) to objects (resources), instead of more RPC-like operations. This corresponds to object-capability notions.

2. REST specifies that references (URLs) to objects (resources) shall be obtained from responses from the server (introductions) as opposed to the client having prior knowledge of the format of the URLs (ambient authority, loosely).

Past discussions of the best way to use HTTP in a capability fashion have disagreed with REST on minor issues, such as whether the use of PUT and DELETE is a good idea; but the above two items are points of agreement between REST and capability principles on things you should _avoid_.


> What's an i-node in object capability terms?

Unix inodes are essentially "file objects". If the Unix filesystem were tweaked into being a capability system (the essential change being to delete ".."), then directories could be considered to be a mapping from names to capabilities. Hence, a hard-linked file is a single file object (inode) with two capabilities pointing to it (or two copies of the same capability, depending on the details of the system and how you like to philosophize).


> I'm trying to avoid ambient authority or identity in this description, except for forgeable references and Minecraft.  Have I been successful?

I did not notice any place in your message where you assumed the notions of identity or ambient authority.


> What would be an example of a game that represents best the object-capability model?

I would argue that games are likely to poorly correspond to capabilities.

In a competitive game, there must be mechanics to "push back", to respond in kind to one's opponent; capability systems design to avoid such mutual vulnerability. The graph of capabilities, which is the graph of possible causality, is directed and not symmetrical. This argument also applies to games which simulate the physical world, due to the symmetries of physics.

In a cooperative or creative game, there are generally few or no access restrictions within a single instance.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>