localhost_frssoft
/
ocappub
mirror of https://gitlab.com/spritely/ocappub.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

More consistently call Alice/Bob Alyssa/Ben 

This converges on the ActivityPub document
This commit is contained in:
Christopher Lemmer Webber 2019-07-30 15:24:04 -04:00
parent 803472ffe6
commit 0b920742f2
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 77 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

154
README.org
View File

@ -382,43 +382,43 @@ This does not mean that there aren't other layers where we can't
prohibit such activity, but we shouldn't pretend we can prevent it
at the protocol layer.
For example, Alice may converse with her therapist over the
For example, Alyssa may converse with her therapist over the
protocol of sound wave vibrations (ie, simple human speech).
Alice may be expressing information that is meant to be private,
Alyssa may be expressing information that is meant to be private,
but there is nothing about speech traveling through the air that
prevents the therapist from breaking confidence and gossiping
about it to outside sources.
But Alice could take her therapist to court, and her therapist could
But Alyssa could take her therapist to court, and her therapist could
lose her license.
But this is not on the protocol layer of ordinary human speech itself.
Similarly, we could add a "please keep this private" flag to
ActivityPub messages so that Alice could tell Bob to please not
ActivityPub messages so that Alyssa could tell Ben to please not
share her secrets.
Bob, being a good friend, will probably comply, and maybe his client
Ben, being a good friend, will probably comply, and maybe his client
will help him cooperate by default.
But "please" or "request" is really key to our interface, since from
a protocol perspective, there is no guarantee that Bob will comply.
However this does not mean there are no consequences for Bob if he
betrays Alice's trust: Alice may stop being his friend, or at least
a protocol perspective, there is no guarantee that Ben will comply.
However this does not mean there are no consequences for Ben if he
betrays Alyssa's trust: Alyssa may stop being his friend, or at least
unfollow him.
Likewise, it is not possible to attach a protocol-enforceable "do not
delegate" flag onto any form of authority, whether it be an ocap or an
ACL.
If Alice tells Bob that Bob, and Bob alone, has been granted access to
this tool, we should realize that as long as Bob wants to cooperate
If Alyssa tells Ben that Ben, and Ben alone, has been granted access to
this tool, we should realize that as long as Ben wants to cooperate
with Mallet and has communication access to him, he can always set up
a proxy that can forward requests to Alice's tool as if they were
Bob's.
a proxy that can forward requests to Alyssa's tool as if they were
Ben's.
We are not endorsing this, but we are acknowledging it.
Still, there is something we can do: we could wrap Bob's access to
Alice's tool in such a way that it logs that this is the capability
Alice handed to Bob being invoked every time it is invoked, and
disable access if it is misused... whether due to Bob's actions,
Still, there is something we can do: we could wrap Ben's access to
Alyssa's tool in such a way that it logs that this is the capability
Alyssa handed to Ben being invoked every time it is invoked, and
disable access if it is misused... whether due to Ben's actions,
or Mallet's.
In this way, even though Alice cannot prevent Bob from delegating
authority, Alice can hold Bob accountable for the authority granted
In this way, even though Alyssa cannot prevent Ben from delegating
authority, Alyssa can hold Ben accountable for the authority granted
to him.
If we do not take this approach, we expose our users to harm.
@ -527,19 +527,19 @@ network effect of having this be the foundation is re-centralization.
Furthermore, it doesn't even reflect human behavior; few people
belong to only one community.
Alice may be a mathematics professor at work, a fanfiction author
Alyssa may be a mathematics professor at work, a fanfiction author
in her personal time, and a tabletop game enthusiast with her friends.
The behaviors that Alice exhibits and norms of what is considered
The behaviors that Alyssa exhibits and norms of what is considered
acceptable may shift radically in each of these communities, even if
in all of these communities she is Alice.
in all of these communities she is Alyssa.
This isn't duplicitous behavior, this is normal human behavior,
and if our systems don't allow for it, they aren't systems that
serve our users' needs.
But consider also that Alice may have one email account, and yet may
But consider also that Alyssa may have one email account, and yet may
use it for all three of these different communities' email mailing
lists.
Those mailing lists may be all on different servers, and yet Alice
is able to be the right version of Alice for each of those communities
Those mailing lists may be all on different servers, and yet Alyssa
is able to be the right version of Alyssa for each of those communities
as she interacts with them.
This seems to point at a mistake in assumptions about the federated
social web: the instance is not the community level, because users
@ -692,45 +692,45 @@ We will get into the technicality of how to implement ocaps in
The foundation of our system will rely on establishing trust between
two parties.
If Alice trusts Carol to be able to perform an action, she might
If Alyssa trusts Carol to be able to perform an action, she might
"give consent" to Carol.
However, giving consent to Carol is not necessarily permanent; Alice
However, giving consent to Carol is not necessarily permanent; Alyssa
has the tools to track abuse of her resources, and if she sees that
Carol is irresponsible, she can revoke her consent to Carol.
(While Carol could have handed this authority to someone else, Alice
(While Carol could have handed this authority to someone else, Alyssa
would still see the abuse coming from the access she handed Carol,
and could still hold Carol responsible.)
What about users that do not yet trust each other?
If Alice does not yet know or trust Bob, it is up to Alice's default
settings as to whether or not Bob has any opportunity to message Alice.
Maybe Alice only gets messages from entities she has existing
If Alyssa does not yet know or trust Ben, it is up to Alyssa's default
settings as to whether or not Ben has any opportunity to message Alyssa.
Maybe Alyssa only gets messages from entities she has existing
relationships with.
However, it is possible that Alice could have a "default profile"
However, it is possible that Alyssa could have a "default profile"
that anyone can see, but which bears a cost to send a message through.
Perhaps Bob can try to send a message, but it ends up in a moderator
Perhaps Ben can try to send a message, but it ends up in a moderator
queue.
Or, perhaps Bob can send Alice a message, but he must attach "two
Or, perhaps Ben can send Alyssa a message, but he must attach "two
postage stamps" to the message.
In this case, if the message was nice, Alice might refund Bob one
In this case, if the message was nice, Alyssa might refund Ben one
or both stamps.
She might even decide to hand him the authority to send messages to
her in the future, for free.
But say Bob is a spammer and is sending a Viagra ad; Alice can keep
But say Ben is a spammer and is sending a Viagra ad; Alyssa can keep
the stamps.
Now Bob has to "pay" Alice to be spammed (and depending on how we
decide to implement it, Alice might be able to keep this payment).
Now Ben has to "pay" Alyssa to be spammed (and depending on how we
decide to implement it, Alyssa might be able to keep this payment).
There is always a cost to unwanted messages, but in our current
systems the costs lie on the side of the receiver, not the sender.
We can shift that dynamic for unestablished relationships.
And critically, it is up to Alice to decide her threshold: if she is
And critically, it is up to Alyssa to decide her threshold: if she is
receiving abusive messages, she can up the number of stamps required,
disable her public inbox entirely, or hand over moderation to a
trusted party during a particularly difficult period.
But even if she disables her inbox, the parties which have existing
trust relationships with Alice can still message her at no cost.
trust relationships with Alyssa can still message her at no cost.
While we do not claim that we can fully model a system of consent in
this system, we can provide the
@ -800,28 +800,28 @@ some interesting things we could do:
construct and hand the valet a "valet key" that only permits
driving five miles and won't open the glove box or trunk.
Sorry kid, you're not getting a joy ride this time.
- *revocation*: Let's say that Alice wants to allow her roommate
Bob to drive her car, but she also wants to be able to take away
that right if Bob misuses it or if they stop being roommates.
Alice can make a new car key that has a wire inside of it;
Alice holds onto a device where if she presses the button, the
- *revocation*: Let's say that Alyssa wants to allow her roommate
Ben to drive her car, but she also wants to be able to take away
that right if Ben misuses it or if they stop being roommates.
Alyssa can make a new car key that has a wire inside of it;
Alyssa holds onto a device where if she presses the button, the
key "self destructs" (ie the wire melts).
Now Alice can stop Bob from being able to drive the car if she
Now Alyssa can stop Ben from being able to drive the car if she
wants to (and if she does, it'll also disable access to anyone
else Bob has delegated a key to).
- *accountability*: Alice has multiple roommates, and while she would
else Ben has delegated a key to).
- *accountability*: Alyssa has multiple roommates, and while she would
like to allow them all to drive her car, the next time someone
spills a drink in the car and doesn't clean it up, she wants to know
who to blame by seeing who drove the car last.
Alice can achieve this via *composition*: she installs a separate
Alyssa can achieve this via *composition*: she installs a separate
"logging" panel into the dashboard of her car, to which she has the
capability to view the logs.
Next, for the keys that she hands her roommates, she composes together
access to drive the car with the logging service and associates each
key with her roommate's name.
Now each time one of her roommates uses one of these keys, the logging
console (which only Alice has access to) takes note of the associated
name, so Alice can check who left a mess last.
console (which only Alyssa has access to) takes note of the associated
name, so Alyssa can check who left a mess last.
You may have noticed that as we went further in the examples, the
ability to construct such rich capabilities on the fly seemed less
@ -912,8 +912,8 @@ whenever we need them... authority can be handed over "just in time".
This is less surprising if we consider the way passing around ocap
references resembles the way people develop social relationships.
If Alice knows Bob and Alice knows Carol, Alice might decide it is
useful to introduce Bob to Carol.
If Alyssa knows Ben and Alyssa knows Carol, Alyssa might decide it is
useful to introduce Ben to Carol.
We see this all the time with the way people exchange phone numbers
today.
"Oh, you really ought to meet Carol! Hold on, let me give you her
@ -935,8 +935,8 @@ transaction infrastructure, can be modeled on ocaps).
In this paper "Granovetter Diagrams" such as the above are introduced,
showing how ocaps flow through a system by social introductions.
In fact the above diagram is pretty much exactly the same as our phone
number exchange... "Alice is sending Bob the message =foo=, which
contains a reference to Carol, and now Bob has been introduced to /
number exchange... "Alyssa is sending Ben the message =foo=, which
contains a reference to Carol, and now Ben has been introduced to /
has access to Carol."
It turns out that Granovetter Diagrams have their origin in sociology,
@ -1209,7 +1209,7 @@ How about the rest?
It turns out that one abstraction gives us all the power we need:
simple, humble, everyday proxies.
Let's say Alice has a file on a file storage server corresponding to a
Let's say Alyssa has a file on a file storage server corresponding to a
list of people she would like to invite to a party.
It is going to be an enormous birthday bash, so she decides she needs
to keep track of the participants:
@ -1227,12 +1227,12 @@ This file object can accept any of the following two methods:
- *=READ=*: Allows you to see who is currently on the list.
- *=WRITE=*: Allows you to completely replace the file.
Alyssa would like to give Bob, Carol, and Lem access to see who is
Alyssa would like to give Ben, Carol, and Lem access to see who is
on the list, but not to modify the list.
"If you want someone added to the list, you can call me up and
ask me to add them, but for now I'll just give you read access."
She makes separate read-only capabilities to give to Bob and Carol.
She makes separate read-only capabilities to give to Ben and Carol.
These have the following addresses:
: # aka <PARTY-FILE-READ-ONLY-1>
@ -1240,11 +1240,11 @@ These have the following addresses:
: # aka <PARTY-FILE-READ-ONLY-2>
: https://filestore.example/obj/DV9E9-jJaX7wFXtQuRMl1m_91d502cv-_5LX8F-GTn8
She hands these out to Bob and Carol respectively.
She hands these out to Ben and Carol respectively.
Now Bob tries making a =READ= request against =<PARTY-FILE-READ-ONLY-1>=.
Now Ben tries making a =READ= request against =<PARTY-FILE-READ-ONLY-1>=.
It works!
Bob sees that one of his friends isn't on the list yet, so he tries
Ben sees that one of his friends isn't on the list yet, so he tries
to =WRITE= a new copy of the file that has them listed.
Except that this time it throws an error.
How?
@ -1258,15 +1258,15 @@ Due to the nature of object capabilities, this works!
Proxies turned out to be all that was necessary to add this
restriction on use.
Bob calls up Alice and tells her that he appreciates that she wants to
Ben calls up Alyssa and tells her that he appreciates that she wants to
maintain the list, but he has a lot of ideas for people to add, couldn't
he please write to the file?
Alice decides that she completely trusts Bob to add new people to the list
Alyssa decides that she completely trusts Ben to add new people to the list
but he has a bad habit of highlighting text while reading it and accidentally
deleting information.
But adding lines? That seems ok.
Alice makes a new proxy to give to Bob:
Alyssa makes a new proxy to give to Ben:
: # aka <PARTY-FILE-READ-AND-APPEND-1>
: https://filestore.example/obj/VhCCn5LjHKhDny50BIwCU8joyUgKyFIursNhfSgl1SY
@ -1274,15 +1274,15 @@ Alice makes a new proxy to give to Bob:
This new proxy has a =READ= method along with a brand new method that
didn't even exist on the original object called =APPEND= which accepts
as an argument a single line to add to the file.
It was easy for Alice to build this: =APPEND= first does a =READ= against
It was easy for Alyssa to build this: =APPEND= first does a =READ= against
=<PARTY-FILE>=, adds the line to those contents, and does a =WRITE= of the
new version.
Now Bob can =APPEND= as many guests as he wants, but there's no risk of
Now Ben can =APPEND= as many guests as he wants, but there's no risk of
him deleting the current attendees.
Carol hears of Bob's ability to append guests and is jealous.
She calls up Alice and says, can't I get access to =APPEND= also?
Alice trusts Bob to keep the number of guests he added within reason
Carol hears of Ben's ability to append guests and is jealous.
She calls up Alyssa and says, can't I get access to =APPEND= also?
Alyssa trusts Ben to keep the number of guests he added within reason
but she's not so sure about Carol.
She decides to make a new capability to give to Carol:
@ -1290,7 +1290,7 @@ She decides to make a new capability to give to Carol:
: https://filestore.example/obj/NSgn-DCUlbpe7DWTWipF92K09WFdfknYCpJnal0SgoQ
This supports the same kind of =APPEND= method interface as the
=<PARTY-FILE-READ-AND-APPEND-1>= that Alice gave Bob, but it has a new
=<PARTY-FILE-READ-AND-APPEND-1>= that Alyssa gave Ben, but it has a new
restriction: this version of =APPEND= keeps track of an integer, the number
of guests added through that capability.
Once three guests have been added, it will refuse to allow any more
@ -1303,9 +1303,9 @@ proxies just yet!
**** Revocation
Alice is up working late assembling the list when she gets a call from
Alyssa is up working late assembling the list when she gets a call from
Lem offering to help add people to the list.
Alice is very tired and says you know what, sure.
Alyssa is very tired and says you know what, sure.
She gives Lem the capability =<PARTY-FILE-READ-AND-APPEND-2>= and goes
off to bed.
@ -1313,20 +1313,20 @@ She wakes up the next morning and the file is filled with all sorts of
nonsense attendees... most of them don't even have plausible sounding
names!
It's so many additions that Alice knows at least that it couldn't have
It's so many additions that Alyssa knows at least that it couldn't have
been Carol; there were far more than 3 additions to this file.
It must have been Bob or Lem.
It must have been Ben or Lem.
She calls both up in frustration.
Both swear they didn't do it!
Alice decides she doesn't have patience or time for this nonsense and
Alyssa decides she doesn't have patience or time for this nonsense and
decides to cut off access before things get any worse.
Luckily she's well equipped to do so.
We left out a detail when we mentioned the previous capabilities that
Alice handed out... each one of them has an internal switch that can
Alyssa handed out... each one of them has an internal switch that can
be flipped (or, set a flag), at which point they will refuse to
forward messages anymore.
And the power to flip this switch is held by Alice and Alice alone:
And the power to flip this switch is held by Alyssa and Alyssa alone:
: # aka <REVOKE-PARTY-FILE-READ-AND-APPEND-1>,
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-1>
@ -1335,7 +1335,7 @@ And the power to flip this switch is held by Alice and Alice alone:
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-2>
: https://filestore.example/obj/trOC_8Ozfe1KxR8ZC32WcF_edk6dx3826uKslKdxvNI
Alice invokes both of them and poof!
Alyssa invokes both of them and poof!
The corresponding revocation flags are set.
=<PARTY-FILE-READ-AND-APPEND-1>= and =<PARTY-FILE-READ-AND-APPEND-2>=
now both refuse to forward messages.