portal v greeter

[Douglas Crockford]

I need a word for a thing in a capability system that is not a capability that can grant access to capabilities. This is necessary for connecting dynamic distributed systems together.

Currently we are calling it 'greeter', which is nice and welcoming, but does not, I feel, adequately represent its role as gatekeeper. 'Gatekeeper' could work. 'Warden' could work but is too overloaded.

I am liking 'portal'. What do you like?

[randy....@pobox.com]

Concierge?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Matt Rice]

I'm curious what makes you reach for the non-capability verbiage I get
a bit weirded out by the notion of "thing that is not a capability

that can grant access to capabilities".

For the reason that (I don't have a particularly good ref) let me just
quote from http://erights.org/elib/capability/ode/ode-capabilities.html
> In a pure capability operating system, ... a process's only source of authority is the capabilities that it holds.

Which implies this is not a pure capability system, if it is not a
capability and grants access.

I presume this is what was called the "Comm system" in
http://www.erights.org/elib/capability/dist-confine.html alternatively
it could be you are referring to the "Proxy" object described there as
well.
I've honestly never considered it anything more than a resource that
the kernel(s) have access to, each kernel being a tree being a
capability system.
Is the issue here that the remote/far ref might be a reference to
something which violates capability principles?

I'm really not averse to giving this thing a name, I'm more curious
the reasons that it must rise to the level of needing to be described
as "Not a capability".

[Matt Rice]

> I've honestly never considered it anything more than a resource that
> the kernel(s) have access to, each kernel being a tree being a
> capability system.

Sorry I didn't really finish this train of thought, and kind of
intended to just delete it, but forgot to.
I guess I could spiel on about it, and the representation of the union
of capability systems and ambient authority,
and the union of capability systems plural. and their tree vs graph
vs rooted representations...
But I'm not sure I have the wherewithal to come up with a coherent
presentation at the moment, or how your system
would fit such a model. So either ignore that or perhaps probe if it
is something you want to get into.

[Alan Karp]

As I recall, you are using the greeter to bootstrap connectivity.  It is publicly accessible and is used to hand out capabilities based on some criteria.  If that's the case,  you could call it an authorizer.

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

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/218c1527-2a6f-4f84-b535-4d80e933657cn%40googlegroups.com.

[Bakul Shah]

valet?

[Dale Schumacher]

I believe that "greeter" remains the most accurate description, however perhaps a little more explanation of its function would be helpful in narrowing its meaning.

The greeter is an (optional) external access-point that is associated with a network address or endpoint. It sits on the boundary between the system (local capability/addresses) and the network. Messages may arrive from the network at the greeter without a designated capability. Messages are otherwise normal actor messages, delivered to a system-designated actor. The message will usually contain other capabilities (some remote) to which response-messages may be sent by the greeter. The message may contain additional information (maybe some credentials?) that the greeter may use to decide what kind of response (if any) to generate. As Alan mentioned, this is a means of boot-strapping connectivity among otherwise disjoint capability graphs.

This seems to match the function of a "greeter" standing at the front door of a building. The greeter is essentially anonymous, from a capability perspective, and is located strictly by their location relative to the building. Different actors may fill the "greeter" role over time, and if there is no greeter at any given time then no anonymous access is available.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/7C11207B-4383-4372-A1C9-EFEF197D5F42%40iitbombay.org.

[Thomas Greco]

I most certainly expected to see the term "powerbox" mentioned in this thread as this would be the term I would associate with the use-case you've described.

Up until this point, my knowledge of the powerbox pattern comes from the research paper, "How Emily Tamed the Caml". I read for this for the first time roughly 1 year ago in an effort to strengthen my understanding of how the endojs daemon grants/revokes out capabilities to objects. The insight I gained from reading this well exceeded my expectations, and it has had a significant impact on the way in which I view the bootstrapping process that smart contracts go through when being deployed to agoric's blockchain.

I mentioned all of this because this thread led me to a discussion from some years back where people seem to be debating the term powerbox (linked below). I'm wondering if these discussions impacted the  way in which the term is to be used in ocap systems (and has something to do with why it has been left out of this discussion).

http://www.eros-os.org/pipermail/cap-talk/2007-July/008571.html. 

[Alan Karp]

We typically think of a powerbox as holding all the capabilities of a user.  In practice, it's the capability list (c-list) associated with the user agent, the process (actor) that is the user's way into the system.  Doug's greeter has a c-list, as does any actor.  I guess you could call that a power box, but I prefer to keep the concepts separate.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/cc9ea32b-2ff9-4609-82a0-7385daef60e7n%40googlegroups.com.

[Dale Schumacher]

The "greeter" is _not_ a "powerbox", as it's not associated with any particular identity except the target system. However, on systems that have a user-identity concept, providing the user's credentials to the "greeter" may very well _return_ a corresponding "powerbox".

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CANpA1Z21UW5Jkec%3DZvVnJBmM7JBnKbFcNis5Mu5cLOgTkLfP%2BA%40mail.gmail.com.

[Tony Arcieri]

It’s long, but: introducer

Tony Arcieri

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/218c1527-2a6f-4f84-b535-4d80e933657cn%40googlegroups.com.

[Chip Morningstar]

I have memory that there was exactly such a component, if only notionally, in the EC Habitats framework, designed to handle the introduction of an object from one person’s environment into another person’s region.

I cannot remember what we called it, though “gatekeeper” rings a dim bell.  I also have dim sense of “something something terms of service something”, but that’s even fuzzier.

Chip

On Sep 23, 2024, at 3:36 PM, Douglas Crockford <dou...@crockford.com> wrote:

[Chip Morningstar]

The question also touches on my long standing interest in having a standardized way to talk *about* a capability without referencing the capability itself — basically, how do you address the potential infinite regress introduced by rigorously following the practice of never separating designation from authority?

On Sep 23, 2024, at 3:36 PM, Douglas Crockford <dou...@crockford.com> wrote:

[Mark S. Miller]

On Wed, Sep 25, 2024 at 5:35 AM Tony Arcieri <bas...@gmail.com> wrote:

It’s long, but: introducer

That's what E called it. I still like it.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAHOTMVLZvbhnG4SeQ9%3DaymtK6KDj13UAGnJLmSfJPhj9xy%2B2gQ%40mail.gmail.com.

[Mark S. Miller]

On Wed, Sep 25, 2024 at 6:03 AM Chip Morningstar <ch...@fudco.com> wrote:

The question also touches on my long standing interest in having a standardized way to talk *about* a capability without referencing the capability itself — basically, how do you address the potential infinite regress introduced by rigorously following the practice of never separating designation from authority?

ERTP Amounts

 

On Sep 23, 2024, at 3:36 PM, Douglas Crockford <dou...@crockford.com> wrote:

I need a word for a thing in a capability system that is not a capability that can grant access to capabilities. This is necessary for connecting dynamic distributed systems together.

Currently we are calling it 'greeter', which is nice and welcoming, but does not, I feel, adequately represent its role as gatekeeper. 'Gatekeeper' could work. 'Warden' could work but is too overloaded.

I am liking 'portal'. What do you like?

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/218c1527-2a6f-4f84-b535-4d80e933657cn%40googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/B02DAAB2-ECBB-4594-BED1-9F6FF7EA5271%40fudco.com.

[Alan Karp]

Can you explain how that term addresses Chip's question?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK-_AD6FhBfsewVN0Vvp7tsbRd6niWkm20%3DSgb%2BRCgqu6ZD_Tw%40mail.gmail.com.

[Alan Karp]

OAuth calls it the Authorization Server (AS).

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

On Wed, Sep 25, 2024 at 1:18 AM 'Mark S. Miller' via friam <fr...@googlegroups.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK-_AD4HCxdPEsejZOW%2B-i3Ow_ddrsRE%3D-oEQfEc8t%3D_4Lix_Q%40mail.gmail.com.

[Chris Hibbert]

> On Wed, Sep 25, 2024 at 1:18 AM 'Mark S. Miller' via friam
> <fr...@googlegroups.com <mailto:fr...@googlegroups.com>> wrote:
>
>
>
> On Wed, Sep 25, 2024 at 6:03 AM Chip Morningstar <ch...@fudco.com
> <mailto:ch...@fudco.com>> wrote:
>
> The question also touches on my long standing interest in having
> a standardized way to talk *about* a capability without
> referencing the capability itself — basically, how do you
> address the potential infinite regress introduced by rigorously
> following the practice of never separating designation from
> authority?
>
>
> ERTP Amounts

On 9/25/24 8:16 AM, Alan Karp wrote:
> Can you explain how that term addresses Chip's question?

MarkM only named the concept because Chip is very familiar with the
idea, but it's probably new to everyone else here.

At Agoric, we use ERTP payments to capture the notion of currencies.
Each payment is securely provided by an exclusive issuer. Transferring
ownership of the payment gives the recipient exclusive ownership of the
payment.

In order to allow users to cite prices, describe bids, etc, we have a
notion of Amounts. Each Amount includes a Brand (which uniquely
identifies the Issuer) and a value, which says how many or how much of
the currency. Amounts carry no value, but precisely describe a payment,
which would carry the value. I wrote a blog post that tries to capture
the distinction between describing a valuable asset and trasferring that
asset:
https://agoric.com/blog/technology/the-settlers-of-blockchain

Here's the official documentation:
https://docs.agoric.com/guides/ertp/

Chris
--
We are made of the stuff of stars, given our selves by time.
Our duty, as living things, is to be sure that pain is not our
whole story, for we can choose to dance.
---Sherry Tepper, Six Moon Dance
(also see http://lfs.org/newsletter/025/03/SixMoonDance.shtml)

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Alan Karp]

So, unlike a pet name, an ERTP Amount is a way to refer to a capability without being able to use it.  Is that what you were getting at, Chip?

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/a3a2b0bb-2ba4-447e-a32a-1fb3730e05b4%40mydruthers.com.

[Tony Garnock-Jones]

On 9/24/24 00:36, Douglas Crockford wrote:
> does not, I feel, adequately represent its role as gatekeeper.
> 'Gatekeeper' could work.

I've used "gatekeeper" for an analogous role in Syndicate:
https://synit.org/book/operation/builtin/gatekeeper.html

Regards,
Tony

[Douglas Crockford]

This is the only place in a capability system where we explicitly use public addresses, public/private keys, certificates, and access control lists. This should feel like going thru security or passport control. If your papers are in order, you might be granted capabilities. 'Greeter' doesn't feel intimidating enough. It is too friendly. I want to use a term that implies some sort of trial. I like 'gatekeeper' for that reason. I like 'portal' even more because it is shorter.