A safe text-adventure UI and input syntax

[Christopher Lemmer Webber]

Hello... I'm planning the first virtual worlds part of Spritely
(Spritely Fantasary is the virtual worlds part). I'm exploring the idea
of a good old fashioned multiplayer text adventure, a MUD/MOO/etc thing
of some kind. (I'm aware of Den and the "Object-Capability Security in
Virtual Environments" papers; I'm not sure I've grasped all possible
ideas from them though I have tried to gather what I can.)

There are a lot of interesting things to consider. I'm going to
simplify things a bit; I was previously tying my brain into knots, but
realized most of the complexity comes from sources-of-truth when players
have avatars on multiple worlds where those different worlds have a lot
of varying control over avatar behavior. Let's separate that out and
narrow down the following:

- Just one game world (to simplify petnames)

- Petname usage, not unlike in the Secure UIs paper here:
https://github.com/cwebber/rwot9-prague/blob/secure-uis/draft-documents/secure-user-interfaces.md

- We want an input syntax that's unambiguous and consistent, but
sufficiently rich to perform "interesting actions". Contrast to the
following:

- Old text adventure games, such as on the z-machine, often allowed
rich natural language processing but it's also... squishy and
unpredictable full of all sorts of hacks, not unlike English

- Lambdamoo has an input syntax that's unambiguous but limited
to certain sentence constructions:
verb [direct-object [preposition indirect-object]]

- In both cases, "whose method we're invoking" varies... different
objects are given a "chance" to claim and act on the verb. In
z-machine/ZIL games this can vary from scene to scene, but in
lambdamoo it's at least consistent, going from:
- the player who typed the command,
- the room the player is in,
- the direct object, if any, and
- the indirect object, if any.

However the fact that the player typed

- It should be possible to do compositional actions / rights
amplification: invoking a remote object's method and addressing
an object in my inventory might not give it access necessarily;
but it might be possible for me to compose some action to let
it access it.

- Since these kinds of text adventure games are separated, REPL-style,
between an output area ("what's happening") and an input area ("what
I want to do next"), there should be some degree of symmetry between
the two... at the very least, petname system identifiers should be
consistent across the two.

- (Bonus:) It should also be possible to perform some mouse-driven
actions which have textual equivalents

- Critically, on top of all this, it must not feel like a chore to use,
or our user interface won't have users.

So much for requirements. Next up is my proposal for a syntax, but I'll
make that a separate email.

[Kevin Reid]

On Sun, Nov 8, 2020 at 11:42 AM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

   - Lambdamoo has an input syntax that's unambiguous but limited
     to certain sentence constructions:
       verb [direct-object [preposition indirect-object]]

Note that this is unambiguous only so long as noun phrases contains no prepositions, at which point you need to start quoting:

take "the key to my house"

take "the key" to my house

[Christopher Lemmer Webber]

In this post, attempting to sketch out a syntax. If this isn't on-topic
enough for cap-talk let me know... I think it ties in for petname and
ocap UI exploration reasons but am happy to take it off of here if it's
not considered relevant enough to others. However, I think a textual
world style game is just rich enough but also just simplified enough UI
wise to think through some interesting interactions clearly.

Many ideas are drawn from the recent Petnames and Secure UIs writeups
from Rebooting Web of Trust:

https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md
https://github.com/cwebber/rwot9-prague/blob/secure-uis/draft-documents/secure-user-interfaces.md

It's no surprise that there's a correlation between petnames and lexical
scope; Mark called his article "Lambda for Humans":

http://www.erights.org/elib/capability/pnml.html

Likewise, at a REPL, a programmer is also operating within a scope, and
programmers have tended to understand what objects they're operating
upon.

Rough syntax for the different kinds on names in a petname system:

- @bob : petname for bob
- ?cat : self-proclaimed name for a cat in the current "context"
- @bob>carol : edge name bob provides for carol

As such, we might see the following room description:

You are in a ?forest. There is a ?fountain in the middle of
the ?clearing. There are some ?benches here to relax on.
@Smithy is sitting on a ?bench.
@Alice is sitting on a ?bench+1.
@Carol, ?Spartacus, ?Spartacus+1, and ?Spartacus+2 are hanging out.

Here we see that:

- @Smithy, @Alice, and @Carol are all petnames, indicated by the
preceding `@` (which is not part of the petname but is syntax to
identify it as such and allow us to address it). `@` is chosen as
prefix because Twitter has popularized that usage (even though
petnames have better integrity promises than Twitter gives).

- We see here some self-proclaimed names... ?forest, ?fountain,
?clearing, and ?benches are all self-proclaimed names within this
room-context (more on room-contexts in a moment). `?` is chosen as a
prefix exactly because it does not have popular usage, and it looks
immediately "question-able". It does not mean that the name is not
useful, it is a name supplied within a context and may carry some
useful information... but that context does not have the level of
trust we would like.

- We also see some self-proclaimed names with collisions. We have the
NPCs of ?bench, but there is a second bench, ?bench+1 (note that
these are distinct from ?benches, more on that later). Likewise,
we have several users all proclaiming the same name:
?Spartacus, ?Spartacus+1, and ?Spartacus+2.

There is one more naming syntax, though I do not think it will appear in
game contexts (but may in other social network contexts): `@Bob>Carol`
indicates that this is Bob's edge name they describe as Carol. Edge
names are highly desirable but have some tricky edges around privacy,
and are not the focus of this as much as they were in the Secure UIs
Mastodon/Twitter-like social network example. I will come around
to discussing them, as well as "sub-profiles for multiple worlds" in a
followup post, since both introduce some unresolved questions.

Now that we have our syntax to referring to objects, and we can see some
descriptive output, how do we enter input? (To avoid ambituity with
quoting in followup posts I will make the prompt look like `GAME>`)

Basics
======

Here are a few simple commands:

;; Look around, generally
GAME> look
;; Look at the (self-proclaimed) fountain.
;; The first argument is the "direct object" we'd like to interact
;; with, though methods are allowed whatever arity they'd like with
;; whatever meaning for each argument position they'd like.
GAME> look ?fountain
;; Look at the entity which we have petname'd as Smithy
GAME> look @Smithy
;; Place book into a chest.
;; `in ?chest` the application of a keyword argument,
;; like (put #:in "chest") in Guile/Racket,
;; or put(in="chest") in Python
GAME> put ?book in ?chest
;; A string on its own is an implicit "say"
GAME> "Hey everyone, how's it going?"

These actually are shorthands. They expand to the following:

GAME> [.look]
GAME> [.look ?fountain]
GAME> [.look @Smithy]
GAME> [.put ?book in ?chest]
GAME> [.say "Hey everyone, how's it going?"]

What's with the dot? All of these are commands that execute on our
"controller" of our player (the strings by which we generally move our
puppet)... our player's controller has special behavior associated with
each of these method names. So actually, that first one *really*
expands to:

GAME> (pcontrol.look)

Some further expansion is available for the other commands, but before
we get to that, let's pretend we're in a room with a ?dog. We'd like to
pet the dog. Unfortunately, our player controller has no "pet" method,
so this doesn't work:

GAME> pet ?dog
ERROR: player does not have 'pet method

However, the dog *does* have a pet method, which we can invoke:

GAME> ?dog.pet
You pet ?dog on the head. It leans in and pants happily!
GAME> ?dog.pet "belly"
You rub ?dog's belly. It rolls around on the floor happily!
GAME> ?dog.pet "antenna"
It's not possible to pet "antenna" on ?dog!

Expanding these makes the previous dot syntax make more sense:

GAME> [?dog.pet]
GAME> [?dog.pet "belly"]
GAME> [?dog.pet "antenna"]

Expanding on expansion
======================

We mentioned that further expansion is available. There is a
distinction between [] and (), but most users will not use ()... []
interprets game syntax, whereas () is fully expanded scheme that
runs in our client.

GAME> ((room-get "dog") 'pet)
GAME> ((room-get "dog") 'pet "belly")
GAME> ((room-get "dog") 'pet "antenna")

By contrast,

GAME> look @Smithy
GAME> [.put ?book in ?chest]

expands to:

GAME> ((pcontrol 'look) (petname-get "Smithy"))
GAME> ((pcontrol 'put) (room-get "book") #:in (room-get "chest"))

As you can guess, petname-get fetches from our petname database, whereas
room-get fetches from the self-proclaimed names supplied within this
local "room context".

Actually... how does ?Spartacus[...] expand?

GAME> greet ?Spartacus ?Spartacus+1 ?Spartacus+3
GAME> ((pcontrol 'greet) (room-get "Spartacus" 0)
(room-get "Spartacus" 1)
(room-get "Spartacus" 2))

Thus room-get has a default second argument of 0.

Now we can think in terms of scopes. Our game prompt is clearly
basically a REPL, sugar'ified, with some useful bindings. We could
even do:

GAME> (let* ((orig-room-get room-get)
(room-get
(lambda (obj-name num)
(if (equal? obj-name "dog")
(orig-room-get "horse" num)
(orig-room-get obj-name num)))))
[dog.pet])
You pet ?horse, and it neighs happily!

The above redefines within the let scope room-get to rebind ?dog to
?horse. Now why would you want to do that? I have no idea. Just
showing you the general idea here. However the inverse is possible:

(It may be that () scheme syntax has to be turned on in some "advanced"
setting to help newbies not be tricked into giving away their
pcontroller.)

GAME> say (random-phrase)
GAME> say (random-phrase) style "growl"

Could make you say or growl some random curious phrase.

One thing we can observe is that we actually have *three* namespaces (we
might actually need four, one extra for our "inventory"...). One is the
general scheme namespace, unexposed unless () is used (this is partly to
avoid a phishing attack). Within our scheme namespace, petname-get and
room-get are bound to @ and ? respectively.


Moving between rooms
====================

Did you pick up on the clue from `room-get`? Self-proclaimed names are
contextual. Effectively, entering a new room shadows the previous REPL,
rebinding room-get to a new append-only naming context (new names are
added as new entities with no associated petname enter the room). This
also means that game descriptions matching the pre

We might be encountering goblins over and over again in our
game, and ?goblin+95152680 is not going to be meaningful to us.
However, "within" a specific room, we are likely to be able to remember
the difference between ?goblin, ?goblin+1, and ?goblin+2.

This means that if our player heads east, and all three players
self-proclaimed as "Spartacus" follow, the ordering of their names might
be different within the next room. This feels semi-undesirable, but on
the other hand hints at the right thing: that self-proclaimed names are
mostly unreliable and only can be understood within a small context.
We should not expect to remember the difference between ?Spartacus+1 and
?Spartacus+2 the following week from now.

Thus the following useful meme emerges: "If you liked it, you should
have put an @ on it." Let's say we take a liking to ?Spartacus+1 and
want to remember who they are the next time we see them... we could save
them in our petname database as @Sparty and now we can remember who our
friend @Sparty is everywhere.


Strings are quasiquotes
=======================

If we enter a room and say,

GAME> say "Hey Sparty, how's it going?"

this might not make sense to our fellow participants, who don't know who
"Sparty" is.

However, if we do:

GAME> say "Hey @Sparty, how's it going?"

this can translate into "Hey ?Sparticus+1, how's it going?" for Alice,
and "Hey @Spartacular, how's it going?" for Bob, which would be
appropriate to their relevant naming contexts.

This actually means that the above phrase translates to:

GAME> (pcontrol 'say (make-qstring "Hey "
(petname-get "Sparty")
", how's it going?"))

`?` obviously also should work as such, arguably `()` and `[]` as well
though I'm less convinced this is worth the confusion.


Extra notes
===========

- Keywords restricts the kind of syntax allowed. This could be
confusing; an alternative is to use :foo style keywords, but
since we don't *have* to type that character all the time
- Names with annoying characters:
GAME> ?"Harold the \"Mighty\"".praise
- Tab completion should be available in all the same places we expect
for any decent REPL / IDE.


Challenges not yet addressed
============================

- What about petnames and game-world-specific sub-profiles?
- What about petnames and per-room facets vs game-world identity?
- We mentioned the possibility of having an inventory but did not give
it an example.
- What does a sale look like?
- If we teleport a user out of a room and room-get changes its context,
can we perform an attack where we switch out the `?shopkeeper` being
paid? (Do we care?)
- We do not attempt to normalize singular vs plural names. However we
might want to normalize case.

[Christopher Lemmer Webber]

Yep, you're right Kevin... let's put it this way, the way that Lambdamoo
handles it is via a "consistent rule", but one that doesn't escape the
quoting problem you've identified.

[Christopher Lemmer Webber]

I guess more accurately "the problem that requires the ugly quoting
solution".

[Bill Frantz]

I think you have gone a long way toward solving one of the
problems I felt was important in EC Habitats. If different
players have different pet names for a person/object, then when
someone speaks they should see their pet name and not the pet
name used by the speaker.

Consider my friend Mary Rose. When she first started caving,
many people thought her name was Maryrose, surname undefined. In
a pet name system, some may call her Mary and some may call her Maryrose.

We want to see the statement, "@Maryrose isn't coming today.
She's busy." come out with the correct pet name. Note that she
is not present, so we need a solution for the people who don't
have a pet name for her (public key?).

While I'm still trying to cause trouble, I'm going to go all SNL
on you. Consider "Pat". If we substitute @Pat in the sentence
above, then different people may want to see either, "...She's
busy" or, "...He's busy". :-)

Cheers - Bill

On 11/9/20 at 2:12 PM, cwe...@dustycloud.org (Christopher

-------------------------------------------------------------------------
Bill Frantz | Re: Hardware Management Modes: | Periwinkle
(408)348-7900 | If there's a mode, there's a | 150
Rivermead Rd #235
www.pwpconsult.com | failure mode. - Jerry Leichter |
Peterborough, NH 03458

[Alan Karp]

Very interesting.  I haven't read the other emails, but I didn't see a way to express handing out a capability.  

Let's say petting a particular dog is a closely held capability.  If I say, "Pet dog+1" I'm told "The dog ran away from you."  I can imagine saying, "Hey, @Sparty, may I pet your dog?"  How does @Sparty give me that permission?  Does that permission come with a proposed pet name.  For example, @Sparty could say, "@Chris, you may pet >Fido."  Chris would see, "You may pet dog+1 which @Sparty calls >Fido."  Chris can then choose a pet name for @Sparty's dog, but he may already have a @Fido.  In that case, he can call it @Sparty@Fido.  

(We thought a lot about this style of naming when doing Client Utility.)

--------------
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/87lffany44.fsf%40dustycloud.org.

[Alan Karp]

At least you've removed the ambiguity in "time flies."  In your case it would be "time ?flies." if you were doing it with a stopwatch.

--------------
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/87eel2nwz5.fsf%40dustycloud.org.

[Ian Denhardt]

Quoting Bill Frantz (2020-11-09 15:59:22)

> We want to see the statement, "@Maryrose isn't coming today.
> She's busy." come out with the correct pet name. Note that she
> is not present, so we need a solution for the people who don't
> have a pet name for her (public key?).

It seems like maybe one thing to do here is to use the edge names Chris
mentioned. So, if @dustyweb types:

@Maryrose isn't coming today. She's busy.

And I don't have a petname for her, but I do for @dustyweb, I might see:

@dustyweb>Maryrose isn't coming today. She's busy.

...but I have a bunch of questions about how this namespace propagates.
Does that name only show up in my namespace once @dustyweb uses it?
Probably don't want to unconditionally publish all of your petnames...
Does it get updated if @dustyweb changes their local petname? That
sounds undesirable, but if @dustyweb changes to a new name and then
starts using it, what should happen?

...Maybe you could see something like:

?Maryrose (@dustyweb>Maryrose) isn't coming today. She's busy.

After which I have a local name that I can assign a petname to if I
want.

[Raoul Duke]

(hi, i would have guessed sharing pet names would be a no-no, i woulda
assumed they should be treated as private by default at least.)

[Alan Karp]

Raoul Duke <rao...@gmail.com> wrote:

(hi, i would have guessed sharing pet names would be a no-no, i woulda
assumed they should be treated as private by default at least.)

We didn't share pet names in Client Utility.  The example I used was my pet name for my manager, "Dummy."  Clearly, I would be unhappy if certain people knew that.  In Client Utility, I could set things up so others would see "SmartPerson" as a default whenever I referred to my manager using my pet name.

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

[Jonathan Frederickson]

On 11/9/20 2:12 PM, Christopher Lemmer Webber wrote:
> There is one more naming syntax, though I do not think it will appear in
> game contexts (but may in other social network contexts): `@Bob>Carol`
> indicates that this is Bob's edge name they describe as Carol.

I can think of at least one case in which this might come up - referring
to spaces that are particularly relevant to a user. For example, if I
have a "home" space, it might be useful for others to be able to see
that as a `@jfred>home` edge name.

[Christopher Lemmer Webber]

Bill Frantz writes:

> I think you have gone a long way toward solving one of the problems I
> felt was important in EC Habitats. If different players have different
> pet names for a person/object, then when someone speaks they should
> see their pet name and not the pet name used by the speaker.

Yes! I did think about this problem for a while, hence the "string
syntax actually is a kind of quasiquote" approach I described below.

(I also did not know whether or not EC Habitats had solved this problem
fully.)

> Consider my friend Mary Rose. When she first started caving, many
> people thought her name was Maryrose, surname undefined. In a pet name
> system, some may call her Mary and some may call her Maryrose.
>
> We want to see the statement, "@Maryrose isn't coming today. She's
> busy." come out with the correct pet name. Note that she is not
> present, so we need a solution for the people who don't have a pet
> name for her (public key?).

I see what you mean, she's not in the "room". Well, "room-get" may have
been a bit misleading... I initially called it "context-get" but thought
that was too vague. Really it's some sort of "local, temporal context
for self-proclaimed names". So, if someone mentions who is, to them, as
@Maryrose, the other participants who are in the same room (even though
Maryrose isn't) could retrieve that identifier and check its
self-proclaimed name. Assuming no other self-proclaimed "Maryrose"
objects have shown up, this would render as ?Maryrose (then ?Maryrose+1,
?Maryrose+2, etc). If nothing can be found, then I'd suggest going with
?unknown, ?unknown+1, ?unknown+2, etc. (Also, edge names can help here,
but I've been intentionally hand-waving past them for the moment so I'm
mostly continuing that hand-wave.)

Hence it being a "local, temporal context for self-proclaimed names"...
it's less about it being strictly for participants who are in that room,
more about it being a naming context for self-proclaimed names that got
set up when you entered the room and will be abandoned when you leave
it.

BTW, when you leave the room, "old" identifiers should be visibly marked
as being no longer relevant by being faded out or have a strike-through.
It would still be useful to read the names even though they aren't
relevant. Copying and pasting the text referencing them should rewrite
inside the new naming context, with a new ordering of the +1 +2 etc.

> While I'm still trying to cause trouble, I'm going to go all SNL on
> you. Consider "Pat". If we substitute @Pat in the sentence above, then
> different people may want to see either, "...She's busy" or, "...He's
> busy". :-)

I'd consider that more of historical cruft in English in making gendered
pronouns a high priority, syntax-wise. Anyway, maybe Pat's profile can
provide guidance on what pronouns to use if this is important.

[Christopher Lemmer Webber]

Ian Denhardt writes:

> Quoting Bill Frantz (2020-11-09 15:59:22)
>
>> We want to see the statement, "@Maryrose isn't coming today.
>> She's busy." come out with the correct pet name. Note that she
>> is not present, so we need a solution for the people who don't
>> have a pet name for her (public key?).
>
> It seems like maybe one thing to do here is to use the edge names Chris
> mentioned. So, if @dustyweb types:
>
> @Maryrose isn't coming today. She's busy.
>
> And I don't have a petname for her, but I do for @dustyweb, I might see:
>
> @dustyweb>Maryrose isn't coming today. She's busy.

It's a possibility, and a good idea... it's what we advocated in the
Secure UIs paper. But I left this out for two reasons:

1) It ties into a different complexity I haven't gotten into yet about
sub-profiles, and...

And that's 2). But I'm not convinced that makes it completely a
no-go; via rights amplification or other routes, only a limited audience
might have access to your edge names (maybe even different audiences
have different access). I don't have fully researched answers for the
privacy issues, and that's one of two reasons I left it out of this
proposal so as to not have it be a big distraction (yet).

But yes, one can do a lot of inference about what social groups a person
is apart of by analyzing edge name graphs. It's a real concern, and
we've seen historical examples of malicious governments rounding up
activists by association; that's one example where we should be
equivalently worried.

Ian Denhardt writes:

> ...but I have a bunch of questions about how this namespace propagates.
> Does that name only show up in my namespace once @dustyweb uses it?
> Probably don't want to unconditionally publish all of your petnames...
> Does it get updated if @dustyweb changes their local petname? That
> sounds undesirable, but if @dustyweb changes to a new name and then
> starts using it, what should happen?
>
> ...Maybe you could see something like:
>
> ?Maryrose (@dustyweb>Maryrose) isn't coming today. She's busy.
>
> After which I have a local name that I can assign a petname to if I
> want.

If you want to keep track of Maryrose from context to context, make your
own petname for Maryrose. The UI should encourage this, maybe by having
an "empty star outline" that becomes a filled-in star outline next to
names, filled in once a name is assigned, or etc. Or, activities such
as "following" a person on social media is a similar opportunity, etc.

- Chris

[Christopher Lemmer Webber]

Yes exactly. My "player controller" would have to have a built-in
action called "time" in that statement you gave.

By contrast, "?flies.time" would allow you to use the flies' timer
method, or something.

[Christopher Lemmer Webber]

Alan Karp writes:

> Very interesting. I haven't read the other emails, but I didn't see a way
> to express handing out a capability.
>
> Let's say petting a particular dog is a closely held capability. If I say,
> "Pet dog+1" I'm told "The dog ran away from you." I can imagine saying,
> "Hey, @Sparty, may I pet your dog?" How does @Sparty give me that
> permission? Does that permission come with a proposed pet name. For
> example, @Sparty could say, "@Chris, you may pet >Fido." Chris would see,
> "You may pet dog+1 which @Sparty calls >Fido." Chris can then choose a pet
> name for @Sparty's dog, but he may already have a @Fido. In that case, he
> can call it @Sparty@Fido.

It's a good question. For now let's simplify things and assume that we
both see the same dog in the room... I see it as ?FidoTheDog or
@Sparty>Fido and @Sparty sees it as @Fido, but both of these resolve in
some way to an eq-sameness identifier. Let's also say I give
@Sparty>Fido a petname of my own, @SpartysDogFido. I'll use that when
referring to the dog identity for the rest of this email.

However, while I can refer to who I see as @SpartysDogFido and @Sparty
sees the same dog as @Fido, and these are *the same id*, @Sparty
nonetheless has some level of authority that I do not, the authority to
pet his dog. Let's assume also that with no special authority, I can do
some other more "publicly available" (to be loose with words) action
with merely a reference to Fido.

So before we get to how *I* can get the authority to pet his dog, let's
just acknowledge a few ways that @Sparty could have authority that I
don't:

- Sparty could simply have a separate capability that gives him more
access to Fido, which he has simply associated with Fido.
- Sparty could use rights amplification to access further methods on
Fido.

How to model this nicely in the UI is a complicated question of its own.
I've been musing on it; on a call not too long ago, Kevin mentioned
"wearing hats" as a way of representing roles... for instance, Sparty
has a "dog trainer hat" which is actually linked to an unsealer that
allows him to pet this dog and maybe some others. Sparty might put this
on which allows him to access other methods. I haven't thought this
fully through... I'm unsure what the right route is.

A less "wearing-oriented" approach could involve another object which
itself holds onto the unsealer for rights amplification... this is not
unlike the warding/incanting stuff I posted not long ago (a variation on
energetic secrets from Joule, as I understand it). Let's say that
@Sparty have a glove that lets him pet some set of dogs, including Fido
(and maybe others), which @Sparty has set to the petname of @glove.
Sparty could then do:

GAME> @glove.pet @Fido
You pet @Fido... he loves it!

Let's simplify our lives a bit and assume the @glove that Sparty has a
built-in method to assist with delegation-plus-association. Assume that
@Sparty's petname for me is @ChrisWebber. He might type:

GAME> @glove.sprout for @ChrisWebber
A vision of a ?glove associated with @ChrisWebber dances before your
eyes.

Remember that this ?glove is different from @glove, it's a
self-proclaimed-name within the local temporal context. But now it's in
Sparty's scope. So Sparty could use the player-controller "esp" method
(to send a private message) to give me access to the glove:

GAME> msg ChrisWebber "If you want to pet @Fido, you can use this ?glove!"

Now I could see that glove in my messages and bind it to a
petname... now I can pet @SpartysDogFido too!

Now, a question... is having a separate object to pet Fido simply too
annoying? Likewise constantly putting on and taking off hats all the
time. It could be that somehow in my UI I create a "composite"
capability that, when "talking about" Fido, still refers to the
same-eqness Fido identity. However, it should smush together the
available methods for my convenience.

That could make my life much easier from a UX perspective. But is it a
good idea? I don't know.

[Christopher Lemmer Webber]

Yes, that's true!

It might also appear on my "profile description" also though.

[Rob Markovic]

On Tue, Nov 10, 2020 at 5:36 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

Now, a question... is having a separate object to pet Fido simply too
annoying?  Likewise constantly putting on and taking off hats all the
time.  It could be that somehow in my UI I create a "composite"
capability that, when "talking about" Fido, still refers to the
same-eqness Fido identity.  However, it should smush together the
available methods for my convenience.

That could make my life much easier from a UX perspective.  But is it a
good idea?  I don't know.

As mature humans, we have the ability to wear many hats transparently, situationally & dynamically without stopping to put on a particular hat.

If we're keeping context, petting Fido automatically selects the right hat/glove/thought process.

[Alan Karp]

Maybe going back to nouns and verbs will help.  You have nouns for the objects you can see, e.g., @Sparty and ?dog.  For each of them you have a set of verbs, e.g., @Sparty->[talk], while Sparty has @Fido->[feed, walk, pet].  If Sparty wants to let you pet his dog, he can say "Let @Chris @Sparty@Fido->[pet]."  Chris will then have the pet verb to go with ?dog.  No need for a physical object (glove) to represent each permission.

Hats are still useful because the set of nouns and verbs you see depends on what role (hat) you take on.  Sparty as a dog trainer may have other nouns (rolled up newspaper) and verbs (swat on nose) than when he's acting just as a dog owner.

I can envision a help menu showing your nouns and verbs for each noun and even an auto-complete feature, such as the ones in IDEs.

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

[Ian Denhardt]

Quoting Christopher Lemmer Webber (2020-11-10 09:38:54)

> If you want to keep track of Maryrose from context to context, make your
> own petname for Maryrose. The UI should encourage this, maybe by having
> an "empty star outline" that becomes a filled-in star outline next to
> names, filled in once a name is assigned, or etc. Or, activities such
> as "following" a person on social media is a similar opportunity, etc.

I suppose there's no reason the UI can't just invent a temporary ?-name
in this scenario. But that leaves the question of how this name is
chosen. I suppose you could just query the underlying capability for
it's "preferred name," and then append a +N if necessary.

...which brings up another question -- when I mention someone by @- or
?-name, it seems I'm attaching a capability to them to the message. What
authority does that capability confer?

[Christopher Lemmer Webber]

Yep, you've asked a key question here.

I'll say that a lot of my thinking here is related to the OcapPub
thoughts:

https://gitlab.com/spritely/ocappub/blob/master/README.org

Generally I think it makes sense that the id talked about is generally
the id that doesn't convey too much authority. In that system, the
"global id" for my username might give you information about me, but
you'd have to spend stamps to send messages to its inbox. But I could
hand out inboxes to different users (making an association with them)
which have lower cost, so when I try to message them it actually does
the right thing and uses my lower cost method.

However, how does this compose with:

- Being able to talk about the same object, but having some exclusive
use-access to it? (Erights gives us the exclusive access bit. Now
think about combining that with "@dustyweb wields the mighty
@DemiAxe"...)
- Room presences, etc

I have more thoughts on this, that's my next email.

[Christopher Lemmer Webber]

I think you're onto something here. I think there's something curious
about it though... you've described something like energetic secrets
here...

However energetic secrets choose non-stringy petnames, and instead use
lexical names that can be passed around. This implies that now we might
have to either:

- Have Fido sign off somehow that this should correspond to "pet"
so that @SpartysDogFido.pet automatically does the right thing
- Or, the thing I get handed shows up as ?pet, and now I need to bind
the verb to a name. Otherwise I will be doing @SpartysDogFido.?pet
or @SpartysDogFido.@pet if I assign it to a petname.

I'm really unsure about whether or not either of those could be
comfortable. Maybe you think there's an alternative or I'm
misunderstanding.

[Christopher Lemmer Webber]

I left some issues unaddressed in the previous proposal to keep life
much easier. I'm still leaving off the edge name issue for now.

Christopher Lemmer Webber writes:

> Challenges not yet addressed
> ============================
>
> - What about petnames and game-world-specific sub-profiles?

Consider a system where we might connect to multiple game worlds, but
each world has a large amount of freedom in how it might affect players.
If we only connect to one game world, we could come to know an @Alice,
and that is the only @Alice of concern to us. However, imagine a portal
is open that we can step through to enter a new game world. @Alice and
I both join that other world, and eventually come to find each other.

Here we have introduced the notion of authorized world-specific
protocols. Well, what should happen with my regard to my petname
system?

- My client could render both as @Alice. This would help me have an
easy sense of cohesive identity. When I connect to different
"islands" in Animal Crossing, I appear to have the same identity on
all, and all players know me as the same user. However, I am pretty
sure the architecture of Animal Crossing is such that the island I
am connected to is truly in control of the representation of my user.
I might pull strings, but the "server" that controls my player might
choose to pull others, making my player dance in ways unintended
by me.

- My client could drop the petname. Here I encounter merely ?Alice.
Perhaps there could be some indicator that "there is linked
sameness"... Maybe it will render as ?Alice* (where the * is not
actually part of the name and is dropped by the input parser, is just
there to indicate to the user that this is connected as a subprofile
of Alice in some way), or could have an icon of a constellation to
the right of the name, or have a purple background. Clicking on
?Alice would indicate this to me. However, what then? I could make
a new petname... @AliceOnFooWorld. This seems tedious.

I'm not really sure what to do about this. I wrote an email describing
different kinds of game worlds... in certain kinds of game worlds, where
I know every action attributed to @Alice was guaranteed to be initiated
by her, I could think of this as all being controlled by the "root
Alice". That's not really the kind of world I'm describing.

The second option thus seems more correct, but undesirable.

It's possible that edge names also help here. For instance, imagine if
there was a convention such as:

@Alice>IDs>FooWorld

Except this is insufficient, since an authorized subprofile is more
ideally bidirectional, where "root Alice" signs off on this being her
FooWorld identity and "FooWorld Alice" signs off on this being linked to
"root Alice". This prevents us from being uncertain what to think when
there's a "race" between:

[@Alice>Ids>FooWorld | @Mallet>IDs>FooWorld]

and Mallet has no legitimate claim.

> - What about petnames and per-room facets vs game-world identity?

The idea of per-room facets I think came from Den originally (?) though
I haven't explored Den much, and is described in:

https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Virtual_Reality/documents/publications/capsec_vr2008_preprint.pdf

The idea is that instead of interacting with avatars directly, we
interact with a revokeable caretaker that represents that avatar. When
an object/user leaves the room, the caretaker is revoked, and we can no
longer interact through it.

I think this probably isn't too complicated... well, with one exception.
Some objects may have room-only methods and methods that work globally,
no matter whether you're in the same room or not.

That might be complicated, at least a little. One route is that the
caretaker could do only a partial revocation of the methods that no
longer apply to that room. I don't really know though. But in a sense,
I think this is a misapplication of the concept: there are really two
frequently separate and distinct kinds of methods being composed
together: room-oriented methods and global-oriented methods.

> - We mentioned the possibility of having an inventory but did not give
> it an example.

Now take the above issue and add the complexity of "multiple of us might
be able to identify and talk about the @LegendarySword but only the one
holding it should be able to attack with it."

You could provide distinct petnames for the object meant to represent
the authority to swing the sword and one to talk about it... but I think
that's going to be broken, UI-wise.

> - What does a sale look like?

Time to go on a walk while it's nice outside, so I'll try to answer this
and the edgenames one after I get back!

[Alan Karp]

I'm probably not the best judge here.  The only text-based game I've ever played is Adventure, and IBM configured it so we only had a limited number of steps.  You can decide whether to read on now that you know I'm speaking from ignorance.

I'm imagining that the representation of the dog shows you the designation you use to refer to it and can show the actions you are permitted to take.  You would then say, "Pet the ?dog."  The game would react if "pet" wasn't one of your allowed verbs for that noun.  It might show the dog running away; it might say it doesn't understand you; it might deduct credits from your account.  That's up to the game.

If you don't want to parse sentences, I can imagine a UI with a way to choose a noun from those available to you and a verb you are allowed to apply to that noun.

--------------
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/87tutx57ew.fsf%40dustycloud.org.

[Alan Karp]

Can you use DIDs to address some of these naming issues?  Alice can choose to use the same DID in multiple worlds.  If you have a 1-1 mapping between your pet name for Alice and her DID, she will appear as @Alice in both worlds.

I don't understand the problem with room vs global permissions.  If you're in the room, you can smash the telephone; if you're not in the room, you can't.  If you're not in the room, you can call the telephone unless someone has smashed it.  It's just revocable forwarders all the way down.

--------------
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/87r1p02926.fsf%40dustycloud.org.

[Christopher Lemmer Webber]

DIDs could be used, but you'd have the same issue. It's a universal
problem where you have a sub-profile that has some level of distinction
from the root profile, I think.

[Alan Karp]

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

DIDs could be used, but you'd have the same issue.  It's a universal
problem where you have a sub-profile that has some level of distinction
from the root profile, I think.

Can't you use a different DID for the sub-profile?  The DID document can record the root/sub relationship.

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

[Christopher Lemmer Webber]

This is maybe best explained in something resembling code. I'll use a
less lispy syntax for this example.

Assume:

GAME> pet @Fido

translates to:

playerController.pet(Fido)

whereas:

GAME> @Fido.pet

translates to:

Fido.pet()

We can see that in the former, this is something related to a general
action our player is configured to handle (similar to "say" or "go" or
etc). The latter is a dog-specific method.

Well, we're used to objects providing their own methods, that's no
problem. But consider you yourself have proposed a situation where, in
initial conditions, @Sparty can do @Fido.pet even though that verb is,
for whatever reason, not immediately available to me... but somethow
they make it available to me. How what changes? How come we move from
a position where Fido.pet() is not possible at first and then is later
when Sparty takes some action?

The initial approach we could take is that Sparty puts my identity on
some list of entities allowed to call Fido.pet(). For some reason Alan
I think you're going to reject that option immediately. ;)

So, if we aren't going to use a separate object like the glove, which
I'm handed, to pet Fido, but still switch from a state where I couldn't
pet Fido to where I can, what options do we have?

Well if we want it to have the same interface, where Fido.pet() was
previously not possible, but now it is, we might have three options:

- Lexical method names (or a more advanced version with energetic secrets)
- String method names and rights amplification
- String method names and object composition

These last two will share a challenge: whether or not they involve a
publishing a "You've Gotta Believe Me" aspect. More on that in a bit.


Lexical method names
====================

Energetic secrets will be similar enough with an additional
sealing/unsealing step. But for the moment let's focus on:

Fido.pet()

conventionally translates to (Python style syntax):

Fido.__call__("pet")

Note that "pet" is a string. But what if it were a lexical variable?

Fido.__call__(pet)

We'd need the pet verb in our scope somehow. We'd also at that point be
needing to create petnames for every verb we might use too. I think
this might actually often be a good idea... but it does make
method-name-discovery in games less likely to work out well. Still, a
syntax for this could be like:

;; I have a petname for it
GAME> @Fido.@pet
;; I'm using a locally scoped self-proclaimed name of the pet
;; method... not unlike getting the PM about the glove
GAME> @Fido.?pet

This means that I actually couldn't pet Fido without having a relevant
method in the first place. But... that could be messy. I might end up
with a lot of different petnames for methods on different objects.
Seems cluttered for this kind of game.


String method names and rights amplification
============================================

So assume that we want to use @Fido.pet instead. This could be
accomplished by rights amplification... before Sparty gives me access, I
might try calling the .pet method and it gives me back a sealed method,
which my game says something like "Looks like you aren't permitted to
pet Fido." After Sparty hands me access, now I can do @Fido.pet.

In this case, somehow Sparty got an unsealer from his side of the game
world to mine... my client, whatever.

Is that via a publish-subscribe mechanism, and my client automatically
recognizes it and decides to try to use this unsealer in the future? Or
another option, I could take some action to associate it from my client
after seeing it...

If it's the former and automatic, my client needs to be sure that this
unsealer really ought to be associated with this object for real to
prevent an interception attack for arguments passed to it. This might
involve trademarks or etc.


String method names and object composition
==========================================

Similar to the above, but instead I'm handed an object that's associated
with Fido but which also has the pet method... my client somehow layers
that into an object that will compose the two together.

Okay, I've written this as coherently as I can tonight. Sorry, probably
not coherent enough.

- Chris

[Alan Karp]

I don't understand why you need pet names for verbs.  They are automatically scoped to the object they operate on.  Hence, you can have "pet" for Sparty's dog and "pet" for Joey's cat with no ambiguity.  In addition, it's reasonable to expect both Sparty and you to use the same verb to denote petting his dog.  You can even use the same designation for two completely different actions.  For example, you can use the verb "type" when talking about a keyboard and when talking about assigning a blood category.  The scoping means there is no ambiguity.

I also don't understand the problem with updating permissions.  Say your c-list entry for Sparty's dog is currently ?dog[see, hear].  If you say, ?dog.pet, the response is that there's no such verb for ?dog.  If Sparty says "Let @Chris pet @Fido,"  your c-list entry will then be ?dog[see, hear, pet], and ?dog.pet will succeed.  Note that Sparty's statement fails if he doesn't have "pet" in his c-list entry for @Fido.  This approach requires pet names and a common designator, e.g, a DID, for Fido.  "Pet" is the common designator for the verb and does not need a pet name.

Here I've assumed that the verbs in your c-list and in your use of the verbs are represented as strings.  The implementation for Fido can do message dispatch based on the provided string.

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

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

[Christopher Lemmer Webber]

Alan Karp writes:

> I don't understand why you need pet names for verbs. They are
> automatically scoped to the object they operate on.

I didn't say you *need* petnames for verbs, I gave three options I saw
as solving the problem, one of which involved petnames for verbs.

> Hence, you can have "pet" for Sparty's dog and "pet" for Joey's cat
> with no ambiguity. In addition, it's reasonable to expect both Sparty
> and you to use the same verb to denote petting his dog.

Sure, again, two of the paths forward I suggested involved such an
approach :)

> You can even use the same designation for two completely different
> actions. For example, you can use the verb "type" when talking about
> a keyboard and when talking about assigning a blood category. The
> scoping means there is no ambiguity.
>
> I also don't understand the problem with updating permissions. Say your
> c-list entry for Sparty's dog is currently ?dog[see, hear]. If you say,
> ?dog.pet, the response is that there's no such verb for ?dog. If Sparty
> says "Let @Chris pet @Fido," your c-list entry will then be ?dog[see,
> hear, pet], and ?dog.pet will succeed. Note that Sparty's statement fails
> if he doesn't have "pet" in his c-list entry for @Fido. This approach
> requires pet names and a common designator, e.g, a DID, for Fido. "Pet" is
> the common designator for the verb and does not need a pet name.
>
> Here I've assumed that the verbs in your c-list and in your use of the
> verbs are represented as strings. The implementation for Fido can do
> message dispatch based on the provided string.

Alan, you're using the phrase c-list here but I'm pretty sure what you
just described is in fact an ACL! But I might be wrong. Let me
rephrase your wording and I think you'll see what I mean, replacing dog
with file and see/hear/pet with read/write/execute:

> Say your c-list entry for Sparty's file is currently ?file[read,
> execute]. If you say, ?file.write, the response is that there's no
> such verb for ?write. If Sparty says "Let @Chris write @File," your
> c-list entry will then be ?file[read, write, execute], and ?file.write
> will succeed.

Heresy!

[Alan Karp]

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

Alan Karp writes:

> I don't understand why you need pet names for verbs.  They are
> automatically scoped to the object they operate on.

I didn't say you *need* petnames for verbs, I gave three options I saw
as solving the problem, one of which involved petnames for verbs.

> Hence, you can have "pet" for Sparty's dog and "pet" for Joey's cat
> with no ambiguity.  In addition, it's reasonable to expect both Sparty
> and you to use the same verb to denote petting his dog.

Sure, again, two of the paths forward I suggested involved such an
approach :)

Sorry.  I misunderstood what you meant when you talked about using strings. 

>
> Here I've assumed that the verbs in your c-list and in your use of the
> verbs are represented as strings.  The implementation for Fido can do
> message dispatch based on the provided string.

Alan, you're using the phrase c-list here but I'm pretty sure what you
just described is in fact an ACL!  But I might be wrong.  Let me
rephrase your wording and I think you'll see what I mean, replacing dog
with file and see/hear/pet with read/write/execute:

> Say your c-list entry for Sparty's file is currently ?file[read,
> execute].  If you say, ?file.write, the response is that there's no
> such verb for ?write.  If Sparty says "Let @Chris write @File," your
> c-list entry will then be ?file[read, write, execute], and ?file.write
> will succeed.

Heresy!

I was explaining how c-lists get changed.  Think of "Let @Chris write @File" be a message from Sparty to Chris passing a write capability to File.  The system  changes the entry for File in Chris's c-list from ?file[read, execute] to ?file[read, write, execute].  The key point is that Chris's identity is not checked when Chris says, "Write ?file some stuff."  Instead, Chris extracts from his c-list the write capability to File to do the write.

 

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

[Christopher Lemmer Webber]

Alan Karp writes:

> Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
>
>> Alan Karp writes:
>>
>> > I don't understand why you need pet names for verbs. They are
>> > automatically scoped to the object they operate on.
>>
>> I didn't say you *need* petnames for verbs, I gave three options I saw
>> as solving the problem, one of which involved petnames for verbs.
>>
>> > Hence, you can have "pet" for Sparty's dog and "pet" for Joey's cat
>> > with no ambiguity. In addition, it's reasonable to expect both Sparty
>> > and you to use the same verb to denote petting his dog.
>>
>> Sure, again, two of the paths forward I suggested involved such an
>> approach :)
>>
>
> Sorry. I misunderstood what you meant when you talked about using strings.

Ah. :)

>> > Here I've assumed that the verbs in your c-list and in your use of the
>> > verbs are represented as strings. The implementation for Fido can do
>> > message dispatch based on the provided string.
>>
>> Alan, you're using the phrase c-list here but I'm pretty sure what you
>> just described is in fact an ACL! But I might be wrong. Let me
>> rephrase your wording and I think you'll see what I mean, replacing dog
>> with file and see/hear/pet with read/write/execute:
>>
>> > Say your c-list entry for Sparty's file is currently ?file[read,
>> > execute]. If you say, ?file.write, the response is that there's no
>> > such verb for ?write. If Sparty says "Let @Chris write @File," your
>> > c-list entry will then be ?file[read, write, execute], and ?file.write
>> > will succeed.
>>
>> Heresy!
>
> I was explaining how c-lists get changed. Think of "Let @Chris
> write @File" be a message from Sparty to Chris passing a write capability
> to File. The system changes the entry for File in Chris's c-list from
> ?file[read, execute] to ?file[read, write, execute]. The key point is that
> Chris's identity is not checked when Chris says, "Write ?file some stuff."
> Instead, Chris extracts from his c-list the write capability to File to do
> the write.

Okay, whew! For a minute I thought the sky must have turned neon green
because I didn't know in what world I was anymore where Alan was
suggesting an implicit identity-oriented authorization check. ;)

To review, earlier I laid out three paths:

- Lexical method names (or a more advanced version with energetic secrets)
- String method names and rights amplification
- String method names and object composition

Only the first involved petnames. The last is exactly what you have
described.

The key thing you said here:

> Think of "Let @Chris write @File" be a message from Sparty to Chris
> passing a write capability to File.

Yes, we are in 100% agreement then. Nothing is implicit then; my
"client" effectively receives a message saying "here's a capability that
will let you ?dog.pet".

So now we agree there is some sort of push notification that lets my
client know that such an option is possible. Now:

- We have to have received this in such a way that we know this
capability *really* sensibly makes sense for ?dog, and will be
directed to ?dog. In this case there's no arguments that would be
passed along, but we could imagine a scenario where instead of
?dog.pet we had ?shopkeeper.buy. If this was actually supplied by
Mallet, Mallet might be able to intercept a purse. There are
multiple paths to being confident this capability legitimately
applies to the ?dog... as Alan would say, we have a
pre-authentication approach or a present-authentication approach (and
Alan would prefer a pre-authentication path), but regardless we want
to be sure. (Note that a certificate chain approach to ocaps
implicitly carries this information on the pet-verb-supporting
capability itself!)

- In order for ?dog.pet to "do the right thing" and uses this *new*
capability in my client... well, that's exactly what I mean by
"object composition". Instead of sending to ?dog directly, our
client now knows that we want to use this other capability for that
method at least (or it could instead redirect to an object that does
something like the "extends" syntax in E).

As for that last one, my question would be: should that happen
automatically? When Sparty sends the message to Chris after typing, to
use Alan's syntax, "Let @Chris write @file", does Chris's client
*automatically* do this composition/redirection for the .pet verb?
Or instead, should Chris receive a message / have an interaction like:

@Sparty offers ?pet-right as a way to "pet" ?dog.
GAME> receive ?pet-right
;; or maybe more explicit, but not know what benefit this allows
;; if we've already authenticated that it applies to ?dog
GAME> receive ?pet-right for ?dog
;; in either case...
GAME> ?dog.pet
You pet ?dog... ?dog wags its tail!

(The UI, presumably, should allow me to see that I've remembered to use
this "right" for ?dog.)

Otherwise it could just happen.

@Sparty has allowed you to "pet" ?dog.
GAME> ?dog.pet
You pet ?dog... ?dog wags its tail!

The problem with this route is, going full Horton, it should be
presumably possible for Sparty to revoke access for Chris to pet the
dog. In that case, knowing that I'm accepting the right to ?dog.pet
from Sparty might be good, because maybe Sparty is fairly capricious and
may take away my rights for no good reason at any time. Perhaps I would
prefer to have my dog-petting-rights from Samantha.

Thoughts?
- Chris

[David Nicol]

My thoughts are, interactive text adventure gaming sounds like an excellent application for the language I call "Motion."

The syntax is

         OP ARG*

where each arg might itself be an OP ARG* sequence, that would collapse.

The "context" of the operation determines if the ops and args make any sense at all, and there is no "core" keyword set.

The idea that the utterances of others would get automatically translated into the player's idiom is brilliant, and it clearly requires an internal representation that would get rendered in the player's idiom before communicating an event to the player.

Translating different pet-names for fellow players is in my opinion thinking too small. Imagine instead, a MUD where players would all interact in their native languages (English, Arabic, Chinese, Italian,  whatever) but each others utterances -- at the cost of getting limited to what can be represented in the internal representation, and thereby losing any fun from making language-specific puns, outside of players sharing the same idiom, but I honestly believe the serious practitioners won't miss that at all -- transparently translated.

World peace!!!

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

... 

Thoughts?
 - Chris

--

"If you are neutral in situations of injustice, you have chosen the side of the oppressor." -- Bshp. Desmond Tutu

[Christopher Lemmer Webber]

David Nicol writes:

> My thoughts are, interactive text adventure gaming sounds like an excellent
> application for the language I call "Motion."
>
> The syntax is
>
> OP ARG*
>
> where each arg might itself be an OP ARG* sequence, that would collapse.
>
> The "context" of the operation determines if the ops and args make any
> sense at all, and there is no "core" keyword set.
>
> The idea that the utterances of others would get automatically translated
> into the player's idiom is brilliant, and it clearly requires an internal
> representation that would get rendered in the player's idiom before
> communicating an event to the player.

Have you looked at lojban? I'm not confident it will work, but I have
thought about lojban as an *intermediate* language for generating
natural language in a variety of languages. However I am uncertain it
can work.

But there are two things here... the command language side (input, "what
I want to do") and the description language side (output, "here's what
happened")... more thoughts on that here:

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

> Translating different pet-names for fellow players is in my opinion
> thinking too small. Imagine instead, a MUD where players would all interact
> in their native languages (English, Arabic, Chinese, Italian, whatever)
> but each others utterances -- at the cost of getting limited to what can be
> represented in the internal representation, and thereby losing any fun from
> making language-specific puns, outside of players sharing the same idiom,
> but I honestly believe the serious practitioners won't miss that at all --
> transparently translated.

It's a fun idea... though, are commands necessarily immediately
translated into output? The question then becomes about whether or not
hidden information is permitted and embraced.

> World peace!!!

Sadly I'm not sure it will result in this, since much violence happens
between speakers of the same language. But it could help, amongst other
structural and social work.

[Christopher Lemmer Webber]

We talked about this (and other things) today on a call and I think we
came to some rough consensus:

- People might have a global identity for their social network, etc
- But people might also have many different identities in different
game worlds. Alter egos, sockpuppets, you name it... it's okay for
people to have different identities.

These should be displayed distinctively, but it's an option (and a good
idea sometimes) to provide ways to see that they are interlinked.
However it might not be that everyone knows that Alan Karp is The Lord
of Carps on some game world, whether or not many suspect it. Alan might
tell Baldur, and Baldur knowing Alan well would believe that Alan would
not lie about such a thing. But Carol, not knowing either super well,
might only come to believe such a thing if a claim is bidirectional.

Also, Baldur introduced the name "sockname", which I had never heard of,
but appearently appeared in some virtual worlds document a long time
ago...

[Christopher Lemmer Webber]

The general sense from a call today would be that a prearranged scenario
where Chris had already set up a relationship where Sparty has a
capability to add that method... a "foreseen" relationship to compose such
rights.

However in the scenario where a new and possibly interesting right is
expressed was "unforeseen", it should be the explicit version, as
discussed above. After all, Chris probably needs to be told that
wagging is now a thing that can be done in order for Chris to have
interest in trying anyway... and this gives the possibility of Chris
being able to consider *whether Chris wants or trusts* using such a
capability for ?dog pet'ing in the future.

- Chris

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Moving between rooms
> ====================
>
> Did you pick up on the clue from `room-get`? Self-proclaimed names are
> contextual. Effectively, entering a new room shadows the previous REPL,
> rebinding room-get to a new append-only naming context (new names are
> added as new entities with no associated petname enter the room). This
> also means that game descriptions matching the pre
>
> We might be encountering goblins over and over again in our
> game, and ?goblin+95152680 is not going to be meaningful to us.
> However, "within" a specific room, we are likely to be able to remember
> the difference between ?goblin, ?goblin+1, and ?goblin+2.
>
> This means that if our player heads east, and all three players
> self-proclaimed as "Spartacus" follow, the ordering of their names might
> be different within the next room. This feels semi-undesirable, but on
> the other hand hints at the right thing: that self-proclaimed names are
> mostly unreliable and only can be understood within a small context.
> We should not expect to remember the difference between ?Spartacus+1 and
> ?Spartacus+2 the following week from now.
>
> Thus the following useful meme emerges: "If you liked it, you should
> have put an @ on it." Let's say we take a liking to ?Spartacus+1 and
> want to remember who they are the next time we see them... we could save
> them in our petname database as @Sparty and now we can remember who our
> friend @Sparty is everywhere.

Kevin added an interesting observation: "leaving a room by going east
and coming back by heading west, a user might desire or expect that
previous names continue to be upheld." Thus it might make sense to keep
N amounts of previous scope sets of history, where N could be some
reasonable default or user defined.

[Kevin Reid]

On Fri, Nov 13, 2020 at 11:59 AM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

Kevin added an interesting observation: "leaving a room by going east
and coming back by heading west, a user might desire or expect that
previous names continue to be upheld."  Thus it might make sense to keep
N amounts of previous scope sets of history, where N could be some
reasonable default or user defined.

Perhaps prioritize the names which the player used — thus ensuring previous commands have previous semantics, without accumulating things the user doesn't care about (a somewhat common UI failure mode of automatically adding objects to a namespace that purportedly belongs to the user).

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> - People might have a global identity for their social network, etc
> - But people might also have many different identities in different
> game worlds. Alter egos, sockpuppets, you name it... it's okay for
> people to have different identities.

Side note, I don't know how it never struck me before, but both used
here:

- id(entity)
- (alter-)ego

I deeply regret slipping into Freudian territory.

- Chris

[Christopher Lemmer Webber]

Kevin Reid writes:

> On Fri, Nov 13, 2020 at 11:59 AM Christopher Lemmer Webber <
> cwe...@dustycloud.org> wrote:
>
>> Kevin added an interesting observation: "leaving a room by going east
>> and coming back by heading west, a user might desire or expect that
>> previous names continue to be upheld." Thus it might make sense to keep
>> N amounts of previous scope sets of history, where N could be some
>> reasonable default or user defined.
>>
>

> Perhaps prioritize the names which the player *used *— thus ensuring

> previous commands have previous semantics, without accumulating things the
> user doesn't care about (a somewhat common UI failure mode of automatically
> adding objects to a namespace that purportedly belongs to the user).

Interesting observation, Kevin!

[Christopher Lemmer Webber]

Last week on Friam, Alan Karp gave a suggestion that took me a while to
parse (initially explained as how client utility did it with c-lists; it
became much simpler once I translated it into object flow), but once
understood dramatically simplified the entire situation. What really
tripped me up, and which I had never considered before, is that a facet
can be a thing by which one might *eventually gain* authority... I have
thought of facets being something where eventually a method might be
revoked from my use. I had never heard of the reverse, where I start
out *without* access to a method through the facet, but where that
method eventually becomes "flipped on" at some point.

Here's the general idea. Chris knows @Sparty, Chris is talking to ?dog.
(From Sparty's perspective, Sparty knows @ChrisWebber, and has @MyDog).

Chris tries to pet ?dog, and fails:

GAME> ?dog.pet
You don't have permission to pet ?dog!

It's important to realize that while the system tries to do some fancy
things so that it appears that Sparty and Chris are talking to each
other about the same dog when they send each other messages, each are
working with a "facet". (The facet is not eq?, but each points at a
universal "profile" of the dog which does not convey much authority but
*is* eq? and is used mostly for checking that we are talking about the
same thing.) Let's say the object graph looks roughly like (sorry
non-fixed-width-font-using-readers):


.-------------------------.
| |
(Sparty) ---> (SpartyDogFacet) -. |
v v
(DogId)------->(DogSoul)
^ ^
(Chris) -----> (ChrisDogFacet) -' |
| |
'-------------------------'

To explain this a bit, Chris and Sparty both have access to their own
respective facets of the dog. Both of these facets point at the
DogIdentity (this allows Sparty and Chris to check if they are talking
about the same dog respectively in their clients, but is not used for
much else... it does not expose much). Both user-facing facets (and the
identity facet) point at the "soul" of the dog... possession of this
capability would allow you to fully act as and control the dog, you
would be the puppetmaster of the dog. However both Chris and Sparty
only have mediated access to the dog. Sparty currently has more
authority to pet than Chris; Sparty can invoke the 'pet method via
SpartyDogFacet whereas Chris cannot via ChrisDogFacet.

What's key here is that, through SpartyDogFacet, Sparty can *flip on*
the authority for Chris to access the 'pet method in ChrisDogFacet!


GAME> allow @ChrisWebber to "pet" @MyDog

The key thing here is that SpartyDogFacet has a special method, for now
let's just call it SpartyDogFacet.__allow(...), that allows for giving
Chris access. It could look like the following:

SpartyDogFacet.__allow(ChrisWebber, "pet")

Note the following: this means that somehow SpartyDogFacet has to be
able to look up what facet Chris has, or something nearly equivalent, so
it can flip on the bit. There is thus a certain amount of identity
here, but only because the users of the game client also have some level
of shared identity.

Anyway, now Chris can pet the dog:

> ?dog.pet
You pet ?dog. It wags its tail enthusiastically!

The real gain here is: we don't have to do anything scary like
"dynamically compose an indirected capability on top of another
capability within the UI", which really made me nervous for all the
previous reasons described.

As far as I know, I've never read anything in the ocap literature yet
about *flipping on* access to methods as opposed to *eventually
revoking* access. But it seems like a powerful (ahem) capability here.

Note that this only works when somehow the Dog's code is in the loop in
being able to enable or disable methods. There are some benefits here:
the dog is able to know *who* enabled Chris access. The dog could also
have let Sparty hand out attenuated access, like "only allow use of the
pet method five times", though without transmitting code (which
introduces a whole realm of complexity), the Dog's code has to be in on
the loop of what kind of attenuations might be available.

But consider that maybe Sparty wants to hand Chris a kind of attenuation
or composition that the Dog had not considered. Maybe Sparty wants to
allow Chris to pet the Dog, but every time Chris pets the dog, Sparty
gets a notification on Sparty's smartwatch saying "Chris just pet the
dog!". This composition was never anticipated by the dog, but hey,
we're ocap people, so we should absolutely allow this. But in this
scenario we're not considering sending code over the wire, so the dog
can't really participate in adding this compositional aspect when
flipping on the pet method for ChrisDogFacet, so we need to do something
else. (Note: there would be potential security and privacy issues;
having ?dog.pet suddenly send information to Sparty might be something
that neither Chris nor especially the Dog would have wanted... in this
case, it *looks like* just invoking the dog's method, so this is a
violation of expectations... it's also dangerous in the case that Sparty
"flips on" a "buy" method on ShopKeeper for Chris, but "composes"
something that redirects the purse to Sparty.)

Thus, the "flipping on" in the facet approach only really works when the
Dog's code has some level of involvement. But there is an
alternative... Sparty could make a new object, ?glove, that Sparty makes
availble to Chris:

@Sparty: Hey @ChrisWebber, try using this ?glove to pet the dog!
> ?glove.pet
You pet ?dog and it wags its tail enthusiastically!

I think this approach solves all of my concerns, and has major wins:

- It's possible for the most common cases in the game to "enable
access" to methods that other users didn't have previously
through facets that may have methods "flipped on".

- It limits "identity" from creeping into our systems too much:
identity is mostly a way for you and I to talk about the same
objects, but identity is not the root of authority in any way.

- It does not have confused deputy problems, which I had feared
were difficult to avoid given the amount of identity that appears in
social systems.

- In the case where the object related to the facet does not have
mechanisms to coordinate granting authority to other users, it is
still possible to construct *new* objects (such as the glove) that
have such access. However such objects look noticeably distinct,
which is a security feature because they may perform behaviors that
are not those encoded by the referenced object (eg Sparty being
informed on his smartwatch of Chris petting the Dog).

I think this is quite good. I'm very excited!

There were a lot of people giving good feedback on the last call; thanks
to Alan Karp, Baldur Jóhannsson, Bill Frantz, Kevin Reid, and Terry
Hayes (I think? I am probably missing some people). Thanks also to
Jonathan Rees who helped me identify many of the problems that were
necessary to solve and framing them.

I'm feeling very positive. A month ago I knew I needed to develop a UI,
but I was not confident that it could reflect the kind of concerns I
had. There are a few things left to resolve, but now, but no longer too
many. This thread has gotten long: I am thinking of making a fresh
document summarizing the details from this plan and publish it in the
Spritely repositories. (I assume there's probably interest in reading
that here once I'm done?)

[Ian Denhardt]

Quoting Christopher Lemmer Webber (2020-11-27 12:53:49)

> @Sparty: Hey @ChrisWebber, try using this ?glove to pet the dog!
> > ?glove.pet
> You pet ?dog and it wags its tail enthusiastically!

My immediate reaction here is: pet what?

?glove.pet ?dog

I'm not sure how much of a footgun I think that is likely to be in
practice. A programmer who understands how ocaps work is probably
unlikely to make that mistake.

<tangent>

But I guess for me this is sort of calling attention to how semantically
bizzare OO code can be. ?dog.pet is fundamentally weird conceptually:
presumably you're intending to pet the dog, but operationally, this is a
_request to the dog_ to "pet," whatever that means. Interpreting this as
you petting the dog has the weird implication that the dog already has
all the authority needed to cause you to pet it, without you doing
anything (you didn't hand it any caps when you did ?dog.pet, after all).

I'm not entirely sure what my point is here, but this has me wanting to
think about ways to do something akin multiple dispatch in an
ocap-friendly way.


I don't know what's been explored in the literature but my brain is
going towards something where you could combine two "capabilities" like:

- pet(_, ?dog)
- pet(@chris, _)

To form a capability for pet(@chris, ?dog). Upon invoking this, both
@chris and ?dog would get a notification of the invocation, perhaps with
the other arguments being "identity only" in the sense of Pony's 'tag'
reference capabilities. So you'd in a sense be invoking a method on
_each_ argument, in contrast to choosing a method based on the
combination of arguments, so this isn't really what people normally mean
by multiple dispatch. It's also super weird from a procedural program
execution standpoint, but perhaps less so from agent based thinking.

This is all super half-baked and I'm sure I'm not expressing it that
well. But I might let it simmer for a while.

</tangent>

[Kevin Reid]

On Sun, Nov 29, 2020 at 7:51 AM Ian Denhardt <i...@zenhack.net> wrote:

But I guess for me this is sort of calling attention to how semantically
bizzare OO code can be. ?dog.pet is fundamentally weird conceptually:
presumably you're intending to pet the dog, but operationally, this is a
_request to the dog_ to "pet," whatever that means. Interpreting this as
you petting the dog has the weird implication that the dog already has
all the authority needed to cause you to pet it, without you doing
anything (you didn't hand it any caps when you did ?dog.pet, after all).

I haven't been entirely following the designs in the rest of the conversation, but this is not necessarily the case. In a virtual world it makes sense (in my opinion) for there to be a category of caps which are "Alice's view of Bob as mediated by the room they are both in".

Under that scheme, the UI-level call ?dog.pet is actually <capability the room gave you to represent the dog, which refers to a facet the dog generated to offer the room>.pet(), and that room-managed facet, when forwarding the pet() message (which in practice is probably something more like interaction("pet")) to provide for systematic handling of new verbs), adds arguments to the message (i.e. subject-to-room-mediator and room-mediator-to-object are slightly different protocols) to make it into interaction(<cap representing your action as seen by the dog>, "pet"), or possibly entirely filters the message (making an access decision) based on criteria established by the room (such as reachability due to virtual physical distance).

Thus, the dog does not already have the authority to cause you-in-particular to pet it; that authority is granted by the act. It just happens that the different layers of intermediaries / user-agents here have different ideas of what's implicit (not in an ambient authority way, but in a "I exist solely to act on behalf of…" way).

A slight improvement to the above protocol, which I realized halfway through writing it but did not want to complicate the description with: the <cap representing your action as seen by the dog> can and probably should not just be made up from scratch by the room, but actually contain something (ocap, signed message, whatever) generated by your UA for the single action. That way, while the room as shared environment can still mislead others about the nature of your actions, it can't claim you are taking actions repeatedly when you only did something once, and your part can embed "I was intending to 'pet' a 'dog'" so as to add auditability against misrepresentation.

To summarize the point: "dog.pet()" is not weird as long as the dog is a capability you hold that is your particular access to the dog.

[Christopher Lemmer Webber]

Ian Denhardt writes:

> Quoting Christopher Lemmer Webber (2020-11-27 12:53:49)
>
>> @Sparty: Hey @ChrisWebber, try using this ?glove to pet the dog!
>> > ?glove.pet
>> You pet ?dog and it wags its tail enthusiastically!
>
> My immediate reaction here is: pet what?

It's indeed weird from a language perspective, but not from an ocap
perspective, if this is a glove that is only designed to pet the dog as
a facet. Which might mean that players' intuitions are violated.

> ?glove.pet ?dog

Which could work, but in order to have granted this authority, it would
probably do so by rights amplification.

> I'm not sure how much of a footgun I think that is likely to be in
> practice. A programmer who understands how ocaps work is probably
> unlikely to make that mistake.
>
> <tangent>
>
> But I guess for me this is sort of calling attention to how semantically
> bizzare OO code can be. ?dog.pet is fundamentally weird conceptually:
> presumably you're intending to pet the dog, but operationally, this is a
> _request to the dog_ to "pet," whatever that means. Interpreting this as
> you petting the dog has the weird implication that the dog already has
> all the authority needed to cause you to pet it, without you doing
> anything (you didn't hand it any caps when you did ?dog.pet, after all).

Let's be clear: here you mean "how bizarre method dispatch can be",
since OO can mean many things:

http://mumble.net/~jar/articles/oo.html

I agree there's some level of strangeness in the following way... I've
sometimes written some game code and I've wondered whether or not adding
a robot.attack() method would mean to the reader "attack the robot" or
"the robot should attack". robot.beAttacked() would be clearer.

However I'm not sure that OO is unique in this strangeness. Consider
the glove example again... we could remove the .pet() verb and just
treat this as a function, glove(). That's *still* strange.

> I'm not entirely sure what my point is here, but this has me wanting to
> think about ways to do something akin multiple dispatch in an
> ocap-friendly way.
>
>
> I don't know what's been explored in the literature but my brain is
> going towards something where you could combine two "capabilities" like:
>
> - pet(_, ?dog)
> - pet(@chris, _)

I think this comes close to ocaps + logic languages, which I think is
a... tricky area. I know MarkM and some others have done some research
but part of the weird thing about combining ocaps + logic languages here
is the implications of adding *effects* to object languages. Games are
fundamentally corrupted from a logic perspective by the experience of
time and change, or so I've considered...

> To form a capability for pet(@chris, ?dog). Upon invoking this, both
> @chris and ?dog would get a notification of the invocation, perhaps with
> the other arguments being "identity only" in the sense of Pony's 'tag'
> reference capabilities. So you'd in a sense be invoking a method on
> _each_ argument, in contrast to choosing a method based on the
> combination of arguments, so this isn't really what people normally mean
> by multiple dispatch. It's also super weird from a procedural program
> execution standpoint, but perhaps less so from agent based thinking.

I've thought about similar things when studying lojban and considering
applying it to an ocap'y adventure language. Particularly the way that
lojban has "arity/slots" and only some might be filled at any time...

https://mw.lojban.org/papri/la_karda

I get confused around several points though:

- The seeming distinction between "command language" versus
"descriptive language" (see the table I wrote up recently)
- Whether or not any alterations need to be applied to the notions of
identity + facets + something.
- "Where does the action and authority structure start?" I can think
about this when starting with the glove as the thing initiating the
action, but I get lost when I think beyond that.

> This is all super half-baked and I'm sure I'm not expressing it that
> well. But I might let it simmer for a while.
>
> </tangent>

I think it's a good tangent! Note that I'm not claiming the syntax I've
derived is perfect, but maybe at least a useful enough level of
advancement that I can conceive of implementing right now while
disambiguating some of the thornier pieces.

- Chris

PS: traditional text adventure games do let some object "win" and start
handling the command, it's just a bunch of hidden machinery as to who is
going to win. In some ways I've tried to mostly not depart too far from
traditional text adventure games, such as the infocom/z-machine games,
but just try to be clearer about syntax and command-handling than such
systems.

[Christopher Lemmer Webber]

> different ideas of what's *implicit* (not in an ambient authority way, but

> in a "I exist solely to act on behalf of…" way).
>
> A slight improvement to the above protocol, which I realized halfway
> through writing it but did not want to complicate the description
> with: the <cap
> representing your action as seen by the dog> can and probably should not
> just be made up from scratch by the room, but actually contain something
> (ocap, signed message, whatever) generated by your UA for the single
> action. That way, while the room as shared environment can still mislead
> others about the nature of your actions, it can't claim you are taking

> actions *repeatedly* when you only did something once, and your part can

> embed "I was intending to 'pet' a 'dog'" so as to add auditability against
> misrepresentation.
>
> To summarize the point: "dog.pet()" is not weird as long as the dog is a

> capability you hold that is *your particular access* to the dog.

Kevin, your summary seems to match how I've been thinking about things.

However I think Ian does raise a separate point which is that this seems
potentially strange to a *game player* as opposed to an *ocap
engineer*. However it's possible that through continued play that
players will develop an engineer-like intuition over time. The only way
to know I guess is to put it in the hands of players...

Back to hacking...