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