Re: Joins on capabilities that have passed through different membranes

I think the thing i was trying to get at, is that this "drag and
dropped onto the desktop" action that Carol initiates to escape Bob
and Alice's authority,
and interpret Bob and Alice's capabilities within Carols authority

Mainly because I don't think its as simple as which authority on
bob/alices capabilities to invoke, but which of Carol's authorities to
invoke on which of Carol's capabilities, and subsequently where the
result belongs, I don't think its a decision anyone but Carol can
make.


On Tue, Jan 5, 2016 at 6:20 PM, Marc Stiegler <[email protected]> wrote:
> "Humans, meanwhile, are much worse at managing multiple capabilities to the
> same object than computers are. So in the interest of UX, we make a
> compromise by auto-joining capabilities when they land in a human's
> capability store."
>
>
> So, I keep on pressing people to think of capabilities as being like
> documents, and managing them as documents, which is very simple and easy to
> do with webkeys that are dragged and dropped onto the desktop from the
> browser and auto-converted into shortcut docs.
>
> Consider the following example: Carol is working with Alice on project A,
> and with Bob on project B. Both project A and B involve using document D.
> So:
>
> Carol has all her project A docs in folder ProjA, and her project B docs in
> folder projB.
>
> Alice sends Carol a webkey for D. Carol drops it into folder projA. When
> working on A, Carol clicks the webkey in projA.
>
> Bob sends Carol a webkey for D. Carol drops it into folder projB. When
> working on B, Carol clicks the webkey in projB.
>
> It never makes a difference to Carol whether the cap for A and the cap for B
> are pointing at the same document or not: they might be pointing at
> variations of D that are intended to be merged another day, Carol does not
> care! She uses the correct cap in the correct context, and it just works
> right.
>
> Humanity solved the problem of managing caps when Xerox invented the desktop
> metaphor for document organization, because we already have the facility to
> make caps behave as docs. We just have to recognize that this problem is
> solved, and use the solution.
>
> --marcs
>
> On Tue, Jan 5, 2016 at 5:05 PM, Matt Rice <[email protected]> wrote:
>>
>> I'm not sure its something normal users would want to work with, but
>> Personally, I think it'd be nice to view the current applications
>> capabilities
>> in the context of my directory structure...
>>
>> Mac OSX has a 'proxy icon', thing, from the setRepresentedFilename:
>> method on a window, that can be dragged around to various
>> applications...
>>
>>
>> http://stackoverflow.com/questions/21101562/how-to-have-multiple-proxy-icons-in-cocoa-document-windows
>>
>> I'd prefer something where similar but where  click on the proxy icon,
>> sends the windows capabilties to something like the shelf in:
>>
>>
>> http://debian.uni-duisburg-essen.de/misc/GNUstep/Docs/SystemOverview/pictures/workspace.png
>>
>> I could then select the thing on the shelf to view it within the
>> context of what is labeled the viewing area (where presumably i would
>> have a RW capability sitting nearby)..
>>
>> The shelf, was typically used both as a place to put commonly used
>> things, and as a scratch space for temporary usage, I think this usage
>> requires to keep those two functions separate by some means,
>>
>> so a shelf area for the capabilities from the window, and a shelf area
>> for commonly used stuff, this commonly used area would also see usage
>> as a scratch area when I want to do something with the capabilities
>> from more than one window...
>>
>> worth considering what I recall has been said is that keykos had some
>> fairly long lived capabilities, is it presumed that the [rodoc]
>> received is the most recent and synchronized whenever I edit [rwdoc],
>> or some ancient version where a newer one may already has the
>> requested change...
>> I think its worthwhile to be able to do a reality check, before just
>> editing...
>> I'm not sure it isn't even applicable in those cases we can generally
>> assume a synchronized copy could exist in writer -> editor -> publish
>> scenerios, you generally want to speak about a very specific version
>> of a capability when it comes time publish.
>>
>>
>> On Tue, Jan 5, 2016 at 8:24 AM,  <[email protected]> wrote:
>> >
>> > On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <[email protected]> wrote:
>> >>>
>> >>> Can you provide a concrete example of why one would want to perform
>> >>> the
>> >>> join instead of just using the two capabilities separately?
>> >
>> >
>> > I'm going to take a guess. This is a problem we talked about extensively
>> > during the early parts of the Caja project, and discussed with our
>> > security
>> > PMs. From what I recall, we did not have a good answer.
>> >
>> > * Let's say I have a document I own and have read/write access to. Let's
>> > call my capability to it [rwdoc].
>> >
>> > * I share a read-only cap to that document with Kenton. I say something
>> > like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. Regards."
>> >
>> > * Months later, Kenton replies to me, saying, "Hey Ihab, I think you
>> > need to
>> > add the following information to [rodoc], because some new stuff came
>> > up!
>> > Kthxbai."
>> >
>> > * The cap [rodoc] arrives in my user agent -- browser or whatever. Now
>> > what?
>> > There is no simple "correct" solution.
>> >
>> > -> If my user agent automatically amplifies it to [rwdoc], that means
>> > the
>> > agent has ambient authority. In fact, that's what happens with browsers
>> > and
>> > cookies today! And when you make the situation a bit more complex, with
>> > Kenton's original example, you end up with the joining problem he has
>> > raised.
>> >
>> > -> If my user agent does nothing, then I have "two ways" to get to one
>> > logical document, and we don't know how to explain this state of affairs
>> > to
>> > end-users.
>> >
>> > I think this is a UX research problem. :)
>> >
>> > Ihab
>> >
>> > --
>> > Ihab A.B. Awad, Palo Alto, CA
>> >
>> > _______________________________________________
>> > cap-talk mailing list
>> > [email protected]
>> > http://www.eros-os.org/mailman/listinfo/cap-talk
>> >
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>