[Christopher Lemmer Webber]

An attempt to break down categories. Thinking further about the
relationship between:

- OCaps vs ACLs
- Interactive fiction "input prompt" vs "here's what happened"
- The same, but now for distributed virtual worlds
- Read Eval vs Print (loop!)
- ActivityPub Client to Server (I want to do this next) vs Server to
Server (you want to know that this happened... and know if it could)

And some places where we've seen them hybridized.

Anyway, the table has more details... it's plaintext, but I'm guessing
HTML browsers won't render nicely. Would a volunteer who uses an HTML
client like to paste the following table in some form that preserves
fixed width foo?

https://dustycloud.org/tmp/command-desc-ocap-acl.org.txt

[Mark S. Miller]

Since it is a *.txt file, it rendered fine in my browser. Interesting! Looking forward to your extended explanations.

 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87blgn5j3s.fsf%40dustycloud.org.

[Bill Frantz]

It was nicely formated in FireFox.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz |The nice thing about standards| Periwinkle
(408)348-7900 |is there are so many to choose| 150 Rivermead Rd #235
www.pwpconsult.com |from. - Andrew Tanenbaum | Peterborough, NH 03458

[Tristan Slominski]

Not sure if it'll make sense to you, but another one for your collection if it does:

Command/OCap: Sum type

Descriptive/ID/Judgement: Product type

Hybrid: ?

Very analogous to Program flow (sum type) and Authoring a program (product type). 

I have this weird framing where I frame program execution as using a sum type to discriminate from a product type.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/r480Ps-10146i-478F2A39361E443EAC801C72AA8AC02E%40Williams-MacBook-Pro.local.

[Christopher Lemmer Webber]

I'm not sure what you meant, and admittedly couldn't think of how sum
and product types apply... still interested in what you meant, but Alan
said something on the call that *maybe* felt like it could apply, which
was something close to (Alan, please correct me):

"In an ACL/identity system, you can say nearly anything that you want
to do and then later we find out if you can do it. In an ocap system
your available vocabulary of nouns and verbs is scoped."

That did seem to apply to the sum types and product type thing maybe,
but it also come up again in a different direction... Alan was talking
about how you could have prearranged channels in an ocap system, so eg I
already know this channel is for messages from Alan, or this channel is
messages from the bridge and its lever that makes it go up and down.
Alan correctly pointed out that the "known ocap channels" system can
often be a better communication path where restricted things that can be
said are made. But I asked, what would happen if we were in some
virtual world and I heard "Alan pulls the lever on the bridge, causing
the bridge to open." Alan suggested, have a capability channel
specifically for Alan + bridge. I pointed out that in a sufficiently
rich world, that might mean we'd have to have an ocap channel for every
possible entity + action combination that could happen, etc. Here we're
in a situtation that's also ambient: an ambient amount of communication
that could occur. We could perceive of the bridge opening situation as
being some kind of verifiable credential structure, and this could
accomodate this situation without have to "pre-arrange" a Alan + bridge
communication channel which might never be needed (and could be an
exponential explosion of capability channels that won't be needed).
This actually seems to point to a place where identity/judgement is very
appropriate to a flexible amount of "ambient possible communication",
which is sensing/perceiving/hearing information about information that
has occured... and I can indeed see how that could be a product type,
and this could be an appropriate place *to have* something so flexible
and ambient.

ACLs still remain inappropriate as a combination of identity/judgement +
authorization flows, but I think that places where flexibility in
information that might be shared are places where embracing
identity/judgement and its complexities make sense... *without* using
identity/judgement/authentication as the authorization system itself.

Not sure if that makes much sense. Might write up a summary of the call
from today in general before I go to bed. Lots of nice discussion today.

[Christopher Lemmer Webber]

Mark S. Miller writes:

> On Tue, Oct 27, 2020 at 4:46 PM Christopher Lemmer Webber <
> cwe...@dustycloud.org> wrote:
>
>> An attempt to break down categories. Thinking further about the
>> relationship between:
>>
>> - OCaps vs ACLs
>> - Interactive fiction "input prompt" vs "here's what happened"
>> - The same, but now for distributed virtual worlds
>> - Read Eval vs Print (loop!)
>> - ActivityPub Client to Server (I want to do this next) vs Server to
>> Server (you want to know that this happened... and know if it could)
>>
>> And some places where we've seen them hybridized.
>>
>> Anyway, the table has more details... it's plaintext, but I'm guessing
>> HTML browsers won't render nicely. Would a volunteer who uses an HTML
>> client like to paste the following table in some form that preserves
>> fixed width foo?
>>
>> https://dustycloud.org/tmp/command-desc-ocap-acl.org.txt
>
>
> Since it is a *.txt file, it rendered fine in my browser. Interesting!
> Looking forward to your extended explanations.

Glad to hear your interest. Had a fairly interesting call about it
today on Friam, the original table also based on a call with Jonathan
Rees; thanks to everyone helping shape my thoughts on this. I'm going
to braindump some thoughts from the calls and etc...

- This table/these notes for grouping things was done quickly as I was
capturing some thoughts before I lost them after my call with Rees,
as such I think some things were lost... the first row that lists
OCaps and then ACLs in the first two (non-header) rows may have made
it look like the first two columns were *entirely* about ocaps and
ACLs. While I think everything in the first column can be done
correctly with ocaps, the ACLs are an example of where
identity/judgement are applied in the wrong way, as an authorization
model. However I believe we don't fully escape identity/judgement,
we just scope our problems.

- Alan really wanted to emphasize that we can use ocap channels for
authentication and this is often more correct than ever having
anything eq-compared or using signatures etc; I agree with this
(though think there are cases where it turns out to be insufficient,
explained below). It's a useful toolkit, and in a sense the first
two columns both provide something for each other. But conceptually
I try to leave them as separate.

- The REPL and interactive fiction examples are maybe good ways of
understanding what I mean. Having a REPL open is familiar, and
having an object reference that we can ask for its own
interface/documentation is perfectly valid in an ocap system.
While a programmer is thinking about the structure of their program,
they may interrogate, say, a purse object that's on a remote machine.
That purse may then give its alleged interface, and this may affect
what the programmer does next with the ocaps *the programmer has*
at the next step in the REPL, and satisfied with an appropriate
construction, may codify that into code saved into some file that
guides the use and dissemination of capaiblities held by the objects
which are represented by that new code. But this is alleged; the
purse object could lie about its interface to some degree, and such
a lie could even be just out of date documentation or a regression.
Nonetheless the communication step is still useful... but the sharing
of information is not itself used as an authorization step.

- Similarly, consider an interactive fiction game, with the following
interactions:

> take gun
You take the gun. Its steel is cold against the palm of your hand.

This could be modeled in an ocap object-style system. Consider the
player to have a current scope of objects they can operate on, one
of which is gun. The "take gun" is not far from gun.take() and
indeed many interactive fiction systems do just such a translation.

Now consider the following scenario in this noir-style detective
game:

> talk to cloaked figure
"It's dangerous being in such an alley such as this. You've got a
nice knife there, but here I've got a gun. Two, in fact. Now I'm
your friend, pal. I see your wallet's looking a bit heavy. How
about you hand me some hard cash in exchange for one of these fine
guns... keep you safe on the streets, you know?

> take 500 zorkmids from wallet
You reach into your wallet and pull out 500 zorkmids. The cloaked
figure carefully watches the movements of your hands to make sure
that you don't draw a weapon. He seems satisfied but eager to
take the money. "Come on, hand it over. Let's finish the
transaction."

> hand cash to cloaked figure
You hand over your wad of cash to the cloaked figure, who eagerly
snatches it up. "See pal? I'm good on your offer. We're friends,
see?" He puts the cash in his own wallet and hands you the gun,
open palmed.

> take gun
You take the gun from the cloaked figure. As you do so, you get
a glimpse... a scar runs across the palm of his hand. It... looks
familiar.

> look at scar
A sudden flashback of that fateful night, when you lost your dear
wife, makes everything clear. That scar... that's the very same
scar on the hand of the man who murdered your wife!

> shoot cloaked figure with gun
You fire the gun at the cloaked figure. He staggers back in
surprise. "You... you shot me!" he says, staring down at the wound
on his chest...

In this silly noir pulp story, we see several things:

- This really does resemble a REPL interaction... the player inputs
a command that is read, transformed and evaluated as an
appropriate method invocation, propagating world changes and
effects that are then printed out to the player.

- Information being printed, a period of deliberation by the player
as deciding what to do next, resemble the second column of
identity/judgement. The system's read and eval resemble
command/ocap. There is a feedback loop (ha) between the two
parts of this process, but they are different.

- What capabilities are within the player's scope change throughout
the scope of the session. Withdrawing money from the wallet
reduces future opportunities to withdraw money, handing the money
provides access to the gun, and thus the opportunity to shoot.

- The player might be able to type "wave magic wand and turn the
sky purple", but the game is likely to respond with "Wave what?"
Not far from the kind of error we might see at a normal REPL
interaction.

- But more than that, what opportunities are allegedly available
are mediated by the story the game tells. The player may not
know that buying a gun is *even an option* until the cloaked
figure mentions it is. At that point the player must decide...
"is it a good idea to buy the gun?" The player is making a
judgement call... the game is not forcing this action, but not
doing so might have other, different effects.

- The game also provides some interesting information not only
on what *can be done*, but what *allegedly has happened*. The
reveal of the scar as being the same from the hand of the person
who shot the detective's wife is not directly a communication
about what further capabilities are available, but does inform
the player enough that they decide how to *use* one of the
capabilities they have.

- A fun game, if a bit violent (but thankfully, fictionally so). The
stakes here are not high for the player, other than possibly losing
the game. But in some ways this is not far from the way we think and
interact in our own lives.

- But how does the player know whether what the game is telling them
is... "real"? In this case, the game is really the arbitrator of its
own world of truth, and thus the player can simply immerse themselves
in the reality of whatever the game says.

- Things get more complicated when it's not just one runtime or object
system that's the source of truth. I started to run into this in
ActivityPub, which has both a client-to-server protocol and a
server-to-server protocol. Both use similar structures but I
realized that the same structures appeared very different in each. I
may have a capability through the client-to-server protocol to Create
a Note that says I like pie. But on the server-to-server side,
someone may find a post in their inbox that says that it's from me,
claiming I do or don't like pie. Was it from me or Mallet? Here we
seem to be in some level of identity/judgement land. For the kinds
of posts sent on the ActivityPub network today, it's generally simple
enough... well, there's only one operator, Chris, so we can just see
if Chris signed the message, thus it came from them. It's more
complicated in the example that Alan (allegedly) openins the bridge
by pulling the lever. How do I know that's true? And do I need to
know?

- Kevin correctly pointed out that if we think about many games today,
you might not always have a way for all players in the game to be
able to verify all events, and this can be a source of fun. In some
games, you can shoot a projectile at a sleeping monster who wakes up
and thinks their sleeping buddy is the one that hit them. They now
start to get into a fight, giving you an opportunity to sneak past or
plan a covert attack (or just let the monsters beat themselves up for
you).

- In "real life", it's also demonstratable that most people don't
usually know "how" they know something is true or false. This leads
to some absurd practices, and occasionally errors out very badly (the
severity of this pandemic might be such an example), but in general
it's nonetheless possible for a society to move forward with
participants only having partial or even incorrect information.

- Thus, is it critical that I know that Alan is the one who opened the
bridge? Maybe that depends on my job... am I Chief Bridge Safety
Officer? Okay then, yes. Often otherwise, probably not.

Finally, something fairly different. How do we know what the current
milage and gas level in a car are?

- We could consult an odometer and gas reader that we trust to perform
exactly this task. Maybe we implicitly believe it must be correct
because we understand or have audited the workings of the car. Often
otherwise it might be because we know that tweaking such things to be
incorrect could result in a fine or other penalty. But this is often
a sufficient source of truth. But it might not be the only way.

- We could deconstruct the car into pieces, pull out the gas tank and
pour its gasoline into a container that lets us measure its volume.
This would be quite accurate enough for the gas tank level. We could
also examine the wear and tear on engine and other car components, if
we're sufficiently skilled, and make a rough "guesstimate". "This
isn't new as claimed; this car looks like it's had about 15 years of
heavy use..." However this is imprecise and requires more expertise
than the gas tank... and the ability to dissasemble. Nonetheless
some smalltalk and lisp machine environments are examples of systems
that have allowed such incredible introspection to the appropriately
privileged user.

- If our universe were more deterministic and we were able to log all
times the car has been driven, when its gas tank has been filled,
etc, we might understand the state of the car-relevant part of the
universe to reconstruct its state.

There's another example I'm too tired to provide about weddings and
municipal registries that I think is interesting... maybe tomorow if
there's interest. Or maybe this was too long and braindump'y. (If you
got this far and enjoyed it let me know! Now it's time for bed.)

[Kevin Reid]

On Fri, Oct 30, 2020 at 8:18 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

Alan correctly pointed out that the "known ocap channels" system can
often be a better communication path where restricted things that can be
said are made.  But I asked, what would happen if we were in some
virtual world and I heard "Alan pulls the lever on the bridge, causing
the bridge to open."  Alan suggested, have a capability channel
specifically for Alan + bridge.  I pointed out that in a sufficiently
rich world, that might mean we'd have to have an ocap channel for every
possible entity + action combination that could happen, etc. 

This may be missing the context (I wasn't listening too hard to the "caps versus identity" parts of yesterday's meeting) but I'm going to charge ahead hoping someone gets some use out of the thoughts, and point out that just because you can describe a space of possible actions with a product type doesn't mean it doesn't have capability nature, and you don't have to eagerly instantiate all of it.

Alan is present in the "room"/"space", some element that models a piece of the virtual world which can be occupied. It is, or has, has some notion of where Alan is standing in it. From that, it can construct as needed a capability for the specific action — which, if we're enumerating all possible capabilities, could be identified using a product type (tuple): (Alan-as-the-room-knows-him, lever-as-the-room-knows-it, interact). And, in fact, something like that tuple probably exists in the data structure implementing that capability.

For another example of the same thing with fewer degrees of design freedom than a virtual world, consider a shared capability file system. Several users could have capabilities to a directory. Each capability may have a permission set ('read', 'write', 'create without overwrite', 'submit changes for review', etc.) and also a Horton-style responsibility/attribution-tracking mechanism. If any of these capabilities is used to access a file or subdirectory, a corresponding capability is constructed, with a possibly smaller permission set. Again, there is a tuple which we can use to describe all capabilities native to the filesystem: (directory-or-file, permissions, attribution).

In both of these cases, there is a type of all possible actions — but not all members of it are instantiated as capabilities, not even the ones that are transitively implied by the ones that are.

 

[Alan Karp]

Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

 

(Alan, please correct me):

  "In an ACL/identity system, you can say nearly anything that you want
  to do and then later we find out if you can do it.  In an ocap system
  your available vocabulary of nouns and verbs is scoped."

That's the essence of what I said, but I think you expressed it more coherently than I did.

 

But I asked, what would happen if we were in some
virtual world and I heard "Alan pulls the lever on the bridge, causing
the bridge to open."  Alan suggested, have a capability channel
specifically for Alan + bridge. 

That's not what I intended to say.  That's NxM, which is unscalable. I meant that there is a separate channel for each player who can talk to objects that are part of the castle.  The bridge then knows who pulled the lever.  That information can then be presented to other players in the game on the channels they use to talk with the castle.  This approach is N+M, which I believe is the best you can do while supporting separately revocable capabilities.

 

I pointed out that in a sufficiently
rich world, that might mean we'd have to have an ocap channel for every
possible entity + action combination that could happen, etc.  Here we're
in a situtation that's also ambient: an ambient amount of communication
that could occur.  We could perceive of the bridge opening situation as
being some kind of verifiable credential structure, and this could
accomodate this situation without have to "pre-arrange" a Alan + bridge
communication channel which might never be needed (and could be an
exponential explosion of capability channels that won't be needed).

That description implies that there is a separate channel for every pair of objects, which is clearly unscalable, and is not what I intended to say.  I am assuming there is an Alan vat containing many objects that can act on behalf of Alan and a castle vat that has many objects that Alan's objects can act on.  In that situation, you only need one connection for any of Alan's objects to act on behalf of any of the castle's objects.  On the castle side, there is one c-list for the Alan connection.

 

This actually seems to point to a place where identity/judgement is very
appropriate to a flexible amount of "ambient possible communication",
which is sensing/perceiving/hearing information about information that
has occured... and I can indeed see how that could be a product type,
and this could be an appropriate place *to have* something so flexible
and ambient.

I don't think you need an ambient authority to achieve your goal.  If you want me to be able to see all the objects in a room, you give me a capability when I enter the room to an object that gets all the display information you want me to have.  If there is some object you don't want me to see, you make sure that object doesn't talk to it.  You can have one such object for all participants for globally visible objects, but you can have separate ones if you want selective visibility. 

ACLs still remain inappropriate as a combination of identity/judgement +
authorization flows, but I think that places where flexibility in
information that might be shared are places where embracing
identity/judgement and its complexities make sense... *without* using
identity/judgement/authentication as the authorization system itself.

I think it's better to say that identity/judgement/authentication can be used as the authorization system, e.g., deciding whether to grant a capability., but you don't want to use it to make the access decision. 

Not sure if that makes much sense.  Might write up a summary of the call
from today in general before I go to bed.  Lots of nice discussion today.

Please do write it up.

--------------
Alan Karp

[Alan Karp]

I think Chris and I have a different view of the "who did it" question.  I believe Chris is operating on the assumption that you carry something along with you that lets other players know it's you.  My view is more connection based.  

Before you set up a communications channel with me, you use whatever means you like to decide whether or not to connect and how you will identify requests that come over that channel.  That means Alice can connect to Bob, and Bob will attach the identifier "Alice" to that connection, while Alice can connect to Carol, and Carol will attach the identifier "Bob" to that channel.  If Bob now connects to Carol, she may choose to identify him as "Bob2."  This approach would clearly be confusing in game play, although I can see some fun here.  "Carol, your mission, should you decide to accept it, is to decide if Bob's Alice is your Bob."

The way out, as Chris proposes, is some form of unforgeable credential.  It doesn't prevent Alice from calling herself Bob, but it means that she can't pretend to be Bob2 when talking to Carol.  I believe that's the best you can do without a game-specific authority.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87mu0310e3.fsf%40dustycloud.org.