Re: [friam] Delegation is the Cornerstone of Civilization: Sharing in Sandstorm.io

Ben Laurie <[email protected]> Mon, 11 May 2015 19:26:05 +0100
Newsgroups gmane.comp.capabilities.general
Message-ID <CABrd9STmt=1iXBtzELnJObkm=HPn9g87SLniWBcNFstkj8w35g@mail.gmail.com>
On 11 May 2015 at 17:34, Mark Miller <[email protected]> wrote:
>
>
> On Mon, May 11, 2015 at 5:08 AM, 'Ben Laurie' via friam
> <friam-/[email protected]> wrote:
>>
>> On 8 May 2015 at 15:46, 'Mark S. Miller' via friam
>> <friam-/[email protected]> wrote:
>> > Speaking only for myself:
>> >
>> > I am not aware of any user testing of this issue. User testing is of
>> > course
>> > great if someone foots the bill. But we should also remember that we all
>> > make zillions of decisions based on intuition and guesses not backed by
>> > studies. We cannot afford to do anything else. So lack of user study
>> > should
>> > indeed raise our uncertainty, but it should not mean "we have no idea
>> > until
>> > a study is done". Rather, we do what we do with a zillion decisions we
>> > make
>> > all the time without being able to afford a study -- we argue and
>> > criticize
>> > and build systems and see how people like them.
>>
>> The reason I ask is because to date we have done a terrible job of
>> usability in this space, so I don't buy that our intuitions are worth
>> much. I've been doing some work with a UX researcher recently on
>> end-to-end crypto, another area in which we have traditionally done a
>> terrible job, and the gap between what I think users think and what
>> they actually think is astonishing.
>
>
> Also looking forward to a write up! Any specific results you can tell us
> about in the meantime?

Well, my favourite example so far is that users don't understand that
there's a middle to communications - i.e. if A sends a message to B,
it can only be corrupted or intercepted on either A's or B's machine,
not in between, which is somehow magic. Presumably this is not
universal, and I'll bet its also highly context sensitive.

>> > Regarding the auto-joining, I strongly share this intuition about humans
>> > vs
>> > machines. Much of the difference between the Pet Name Markup Language
>> > <http://www.erights.org/elib/capability/pnml.html> vs Lambda Calculus is
>> > based on this same intuition.
>>
>> Since you mention it, a couple of comments:
>>
>> a) <pn>Bob<s/>Mom</pn> seems to me to be doing violence to XML or HTML
>> or whatever markup it is you think you're using.
>
>
> XML. Do you see anything about it that doesn't conform to XML?
>
> (Not that I care about XML anymore; but that's another matter)

Well, I don't care either, and nor do I claim to be expert, however,
my understanding is that if you want a relationship between two things
in XML, you can't just stick a tag between them, you need instead to
do something like:

<pn-pair><pn-top>Bob</pn-top><pn-bottom>Mom</pn-bottom></pn-pair>

or

<pn-relation bottom="Mom">Bob</pn-relation>

>> b) The idea of looking up "Mom" in "Bob"'s namespace seems to violate
>> the intent of petnames - i.e. I don't care who Bob thinks his Mom is,
>> I care who _I_ think it is.
>
>
> Interesting and valid point. Never occurred to me. Smalltalk '72 (yes, 1972)
> used 's (apostrophe ess) for what modern languages use infix dot for. Your
> observation points out an important semantic difference: "Bob.Mom" would be
> more readily understood by programmers are who Bob's Mom is according to
> Bob, rather than who I think his mom is. But only by programmers
> unfortunately.

True, but I think beside the point - when is someone else's petname
for someone supposed to be useful to me? Surely in general it can't
be?

>> c) You want to be able to express more complex relationships, I
>> would've thought, e.g. Bob's Mom's cleaner.
>
>
> <pn>Bob<s/>Mom<s/>cleaner</pn>
>
> This is subject to the same issue of course -- is this Bob's Mom's cleaner
> according to Bob? Bob's Mom? or according to the person that is Bob's Mom
> according to Bob? pnml says the last, which as you point out differs from
> natural language. But that's already your issue #b. I don't see how #c
> raises any additional issues.

I wasn't suggesting it raised issues, its just you didn't really
define how it worked.

>
>
>
>
>>
>>
>> >
>> >
>> >
>> > On Fri, May 8, 2015 at 2:05 AM, 'Ben Laurie' via friam
>> > <friam-/[email protected]> wrote:
>> >>
>> >> On 5 May 2015 at 17:58, Kenton Varda <[email protected]> wrote:
>> >> > Hi Cap-talk and Friam,
>> >> >
>> >> > Thought you'd find this interesting. We announced the first iteration
>> >> > of
>> >> > Sandstorm's new sharing model today, borrowing a quote from Marc. :)
>> >> >
>> >> >
>> >> >
>> >> > https://blog.sandstorm.io/news/2015-05-05-delegation-is-the-cornerstone-of-civilization.html
>> >> >
>> >> > Note that we're talking about sharing between humans here, which is
>> >> > why
>> >> > we
>> >> > allow capabilities from multiple sources to be auto-joined from the
>> >> > user's
>> >> > point of view. Humans get confused if they have multiple caps for the
>> >> > same
>> >> > document with different rights.
>> >>
>> >> I am curious: have you done any usability testing of this model? If
>> >> so, have you published the results? If not, why not? Would you like
>> >> to?
>> >>
>> >> > But for sharing between computers
>> >> > (capability passing between apps) we will do no such thing.
>> >> >
>> >> > -Kenton
>> >> >
>> >> > --
>> >> > 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> >> > To post to this group, send email to friam-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> >> > Visit this group at http://groups.google.com/group/friam.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> >> To post to this group, send email to friam-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> >> Visit this group at http://groups.google.com/group/friam.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> >
>> > --
>> >     Cheers,
>> >     --MarkM
>> >
>> > --
>> > 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> > To post to this group, send email to friam-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> > Visit this group at http://groups.google.com/group/friam.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> To post to this group, send email to friam-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>> Visit this group at http://groups.google.com/group/friam.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> --
> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> To post to this group, send email to friam-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> Visit this group at http://groups.google.com/group/friam.
> For more options, visit https://groups.google.com/d/optout.