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

Switch Alyssa and Ben over to Alice and Bob 

It makes me sad to drop the SICP characters, but it's consistent with
the grannovetter diagram
This commit is contained in:
Christopher Lemmer Webber 2019-08-17 08:44:41 -04:00
parent 1d826f33ed
commit b7ce44cc04
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 121 additions and 121 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

242
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, Alyssa may converse with her therapist over the
For example, Alice may converse with her therapist over the
protocol of sound wave vibrations (ie, simple human speech).
Alyssa may be expressing information that is meant to be private,
Alice 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 Alyssa could take her therapist to court, and her therapist could
But Alice 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 Alyssa could tell Ben to please not
ActivityPub messages so that Alice could tell Bob to please not
share her secrets.
Ben, being a good friend, will probably comply, and maybe his client
Bob, 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 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
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
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 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
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
with Mallet and has communication access to him, he can always set up
a proxy that can forward requests to Alyssa's tool as if they were
Ben's.
a proxy that can forward requests to Alice's tool as if they were
Bob's.
We are not endorsing this, but we are acknowledging it.
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,
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,
or Mallet's.
In this way, even though Alyssa cannot prevent Ben from delegating
authority, Alyssa can hold Ben accountable for the authority granted
In this way, even though Alice cannot prevent Bob from delegating
authority, Alice can hold Bob 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.
Alyssa may be a mathematics professor at work, a fanfiction author
Alice 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 Alyssa exhibits and norms of what is considered
The behaviors that Alice 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 Alyssa.
in all of these communities she is Alice.
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 Alyssa may have one email account, and yet may
But consider also that Alice 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 Alyssa
is able to be the right version of Alyssa for each of those communities
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
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 Alyssa trusts Carol to be able to perform an action, she might
If Alice trusts Carol to be able to perform an action, she might
"give consent" to Carol.
However, giving consent to Carol is not necessarily permanent; Alyssa
However, giving consent to Carol is not necessarily permanent; Alice
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, Alyssa
(While Carol could have handed this authority to someone else, Alice
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 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
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
relationships with.
However, it is possible that Alyssa could have a "default profile"
However, it is possible that Alice could have a "default profile"
that anyone can see, but which bears a cost to send a message through.
Perhaps Ben can try to send a message, but it ends up in a moderator
Perhaps Bob can try to send a message, but it ends up in a moderator
queue.
Or, perhaps Ben can send Alyssa a message, but he must attach "two
Or, perhaps Bob can send Alice a message, but he must attach "two
postage stamps" to the message.
In this case, if the message was nice, Alyssa might refund Ben one
In this case, if the message was nice, Alice might refund Bob 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 Ben is a spammer and is sending a Viagra ad; Alyssa can keep
But say Bob is a spammer and is sending a Viagra ad; Alice can keep
the stamps.
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).
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).
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 Alyssa to decide her threshold: if she is
And critically, it is up to Alice 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 Alyssa can still message her at no cost.
trust relationships with Alice 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 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
- *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
key "self destructs" (ie the wire melts).
Now Alyssa can stop Ben from being able to drive the car if she
Now Alice can stop Bob from being able to drive the car if she
wants to (and if she does, it'll also disable access to anyone
else Ben has delegated a key to).
- *accountability*: Alyssa has multiple roommates, and while she would
else Bob has delegated a key to).
- *accountability*: Alice 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.
Alyssa can achieve this via *composition*: she installs a separate
Alice 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 Alyssa has access to) takes note of the associated
name, so Alyssa can check who left a mess last.
console (which only Alice has access to) takes note of the associated
name, so Alice 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 Alyssa knows Ben and Alyssa knows Carol, Alyssa might decide it is
useful to introduce Ben to Carol.
If Alice knows Bob and Alice knows Carol, Alice might decide it is
useful to introduce Bob 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... "Alyssa is sending Ben the message =foo=, which
contains a reference to Carol, and now Ben has been introduced to /
number exchange... "Alice is sending Bob the message =foo=, which
contains a reference to Carol, and now Bob has been introduced to /
has access to Carol."
It turns out that Granovetter Diagrams have their origin in sociology,
@ -1091,52 +1091,52 @@ not shown.)
#+BEGIN_SRC javascript
{"@type": "Create",
"actor": "https://chatty.example/ben/",
"to": ["https://chatty.example/ben/followers"],
"actor": "https://chatty.example/bob/",
"to": ["https://chatty.example/bob/followers"],
"object": {
"@id": "https://chatty.example/obj/fQFWD9bZf1GKc3E09gt8W4MlChVxoiMAjgzhqxP9KhE",
"@type": "Note",
"attributedTo": "https://chatty.example/ben/",
"attributedTo": "https://chatty.example/bob/",
"content": "Hello, fediverse! I'm new here. Who should I be chatting with?"}}
#+END_SRC
There is no way to retrieve this object unless you know its address,
but knowing its address allows you to see/refer to it, not unlike the
Google Docs example we referred to earlier.
Ben distributes this message to his local friend group of Alyssa and
Bob distributes this message to his local friend group of Alice and
Lem.
Alyssa thinks that Ben would like to meet her friends and composes
Alice thinks that Bob would like to meet her friends and composes
a reply which refers to his message.
#+BEGIN_SRC javascript
{"@type": "Create",
"actor": "https://social.example/alyssa/",
"to": ["https://social.example/alyssa/collections/my-friends"],
"actor": "https://social.example/alice/",
"to": ["https://social.example/alice/collections/my-friends"],
"object": {
"@id": "https://social.example/obj/Aj1k_Phx4uAgCXOMZ7KP9omJXXnOUySlhP-WXYE0obw",
"@type": "Note",
"attributedTo": "https://social.example/alyssa/",
"attributedTo": "https://social.example/alice/",
"inReplyTo": "https://chatty.example/obj/fQFWD9bZf1GKc3E09gt8W4MlChVxoiMAjgzhqxP9KhE",
"content": "Hey Ben!! Welcome to the network. I want to introduce you to my friends."}}
"content": "Hey Bob!! Welcome to the network. I want to introduce you to my friends."}}
#+END_SRC
In the former message, Ben shared his message amongst his followers
In the former message, Bob shared his message amongst his followers
(which maybe he curates).
In the latter message, Alyssa sent her message, which also provided
a path to Ben's, amongst her friends, encouraging people she knows
to establish a social connection with Ben.
Alyssa and Ben were able to coordinate to spread this communication
In the latter message, Alice sent her message, which also provided
a path to Bob's, amongst her friends, encouraging people she knows
to establish a social connection with Bob.
Alice and Bob were able to coordinate to spread this communication
amongst people they trust, but it is not spread further than to
anyone who is explicitly handed access.
(It's possible that someone can share the information when Ben or Alyssa
(It's possible that someone can share the information when Bob or Alice
asked them not to;
This is mildly interesting, but things get much more interesting when
we realize that inboxes can also themselves be capabilities.
Alyssa is a member of a group of pixel art enthusiasts.
Alice is a member of a group of pixel art enthusiasts.
#+BEGIN_SRC javascript
{"@type": "Group",
@ -1150,25 +1150,25 @@ This pixel art enthusiast group has a public page that anyone can
view at =https://groupchats.example/group/public/pixel-artists=.
However, not everyone who can see that URL has the authority to
post to the group.
At present, Alyssa has the authority to make posts to this group,
At present, Alice has the authority to make posts to this group,
which automatically disseminates them to all members.
However, Alyssa cannot moderate the group (including its membership
However, Alice cannot moderate the group (including its membership
list).
She has limited access.
We will worry about how the limited access is accomplished in a
moment, but for the moment we can say that Alyssa posting to the
moment, but for the moment we can say that Alice posting to the
group is as simple as referencing its =@id=:
#+BEGIN_SRC javascript
{"@type": "Create",
// this is the @id of the above referenced Group object
"to": ["bear:?u=https://groupchats.example/group&t=eQshu8RiJ-9ozh2GKRATXN5-J6dcBVf_AYSMrJ6UEzE"],
"actor": "https://social.example/alyssa/",
"actor": "https://social.example/alice/",
"object": {
"@id": "https://social.example/obj/cdWg7wv1mjrNf0C3vcxCjzPy3Z9tturSBv9_Ew8qe7E",
"@type": "Note",
"attributedTo": "https://social.example/alyssa/",
"attributedTo": "https://social.example/alice/",
"content": "Anyone tried out libresprite? I hear it's a fork of the old FOSS branch of aesprite."}}
#+END_SRC
@ -1176,11 +1176,11 @@ Now the group can forward this message to its subscribers.
Here's the interesting aspects of this:
- Alyssa's access to write to the group can be unique to her. We'll
- Alice's access to write to the group can be unique to her. We'll
see how this can happen in the next section. This means that it's
also easy for the list administrator to unsubscribe her: they can
just revoke the capability.
- As said before, the capability Alyssa has here only allows her to
- As said before, the capability Alice has here only allows her to
post messages, not do moderation.
- !Each subscriber on the group has given the group a specific
capability for their subscription. That means that the messages
@ -1191,7 +1191,7 @@ Here's the interesting aspects of this:
** Adding attenuation, revocation, accountability, and composition
That's all good and well, but even reading the above might hint that
we are missing some things. *How* is Alyssa's capability limited to
we are missing some things. *How* is Alice's capability limited to
posting but not administrating? *How* can both the susbscribers and
the servers both know where messages are "coming from" / hold them
accountable, and also have the power of revocation?
@ -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 Alyssa has a file on a file storage server corresponding to a
Let's say Alice 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 Ben, Carol, and Lem access to see who is
Alice would like to give Bob, 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 Ben and Carol.
She makes separate read-only capabilities to give to Bob 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 Ben and Carol respectively.
She hands these out to Bob and Carol respectively.
Now Ben tries making a =READ= request against =<PARTY-FILE-READ-ONLY-1>=.
Now Bob tries making a =READ= request against =<PARTY-FILE-READ-ONLY-1>=.
It works!
Ben sees that one of his friends isn't on the list yet, so he tries
Bob 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.
Ben calls up Alyssa and tells her that he appreciates that she wants to
Bob calls up Alice 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?
Alyssa decides that she completely trusts Ben to add new people to the list
Alice decides that she completely trusts Bob 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.
Alyssa makes a new proxy to give to Ben:
Alice makes a new proxy to give to Bob:
: # aka <PARTY-FILE-READ-AND-APPEND-1>
: https://filestore.example/obj/VhCCn5LjHKhDny50BIwCU8joyUgKyFIursNhfSgl1SY
@ -1274,15 +1274,15 @@ Alyssa makes a new proxy to give to Ben:
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 Alyssa to build this: =APPEND= first does a =READ= against
It was easy for Alice 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 Ben can =APPEND= as many guests as he wants, but there's no risk of
Now Bob can =APPEND= as many guests as he wants, but there's no risk of
him deleting the current attendees.
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
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
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 Alyssa gave Ben, but it has a new
=<PARTY-FILE-READ-AND-APPEND-1>= that Alice gave Bob, 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
Alyssa is up working late assembling the list when she gets a call from
Alice is up working late assembling the list when she gets a call from
Lem offering to help add people to the list.
Alyssa is very tired and says you know what, sure.
Alice 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 Alyssa knows at least that it couldn't have
It's so many additions that Alice knows at least that it couldn't have
been Carol; there were far more than 3 additions to this file.
It must have been Ben or Lem.
It must have been Bob or Lem.
She calls both up in frustration.
Both swear they didn't do it!
Alyssa decides she doesn't have patience or time for this nonsense and
Alice 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
Alyssa handed out... each one of them has an internal switch that can
Alice 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 Alyssa and Alyssa alone:
And the power to flip this switch is held by Alice and Alice alone:
: # aka <REVOKE-PARTY-FILE-READ-AND-APPEND-1>,
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-1>
@ -1335,38 +1335,38 @@ And the power to flip this switch is held by Alyssa and Alyssa alone:
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-2>
: https://filestore.example/obj/trOC_8Ozfe1KxR8ZC32WcF_edk6dx3826uKslKdxvNI
Alyssa invokes both of them and poof!
Alice 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.
**** Accountability
Both Ben and Lem contact Alyssa and insist neither of them made those
Both Bob and Lem contact Alice and insist neither of them made those
edits to the document.
Couldn't they please get access again to write to the file?
That evening, Alyssa thinks about it and decides that yes, she could,
That evening, Alice thinks about it and decides that yes, she could,
if next time she could hold whoever did it accountable so she could
prevent the problem from happening again and know who violated her
trust.
Alyssa makes two new capabilities, but these ones are a little bit
Alice makes two new capabilities, but these ones are a little bit
different than before: while both allow writing to the file, this time
she associates each one with the name of the person she is handing it
out to.
Now if Bob writes to the file, it's logged that Bob made this change,
and if Lem writes to the file, it's logged that Lem made this change.
Alyssa hands out these new write-capable-but-logging ocaps to Bob and
Alice hands out these new write-capable-but-logging ocaps to Bob and
Lem and logs off for the evening.
The next morning, the file is defaced again.
But the logger picks it up: Lem made all these changes!
Alyssa revokes the capability she gave to Lem and gives him a call
Alice revokes the capability she gave to Lem and gives him a call
on the phone.
Lem swears, he really didn't make these changes!
Alyssa shows him her evidence, and Lem thinks about it.
Alice shows him her evidence, and Lem thinks about it.
Well... Lem is really sure that he didn't make those changes, but
he knows that Mallet wanted access to the file.
It could be that Mallet asked him for it when they went out
@ -1375,13 +1375,13 @@ that opportunity to insert a backdoor into his device.
Lem really isn't sure, but insists that /he/ is not the one that did
it.
Alyssa trusts Lem enough as a person (but not as a person who
Alice trusts Lem enough as a person (but not as a person who
practices good security hygeine), and distrusts Mallet enough, that
she finds this story plausible.
Still she considers with satisfaction that placing the blame "on the
capability she gave to Lem", whether or not it was Lem that did it,
was what she really needed to get to the bottom of the situation.
"For now, you can email me suggestions," Alyssa tells Lem.
"For now, you can email me suggestions," Alice tells Lem.
"But the next time you want to collaborate on a document, make sure
you're more careful with your authority.
And if you're not sure whether Mallet might have a backdoor in your
@ -1396,56 +1396,56 @@ tonight.
# live on her own server
One thing we might notice about the previous example is that we said
that Alyssa set up the endpoint pointed by the capability to "log"
that Alice set up the endpoint pointed by the capability to "log"
information about who was associated with it.
But... where did the logger come from?
The file did not contain this functionality, and capabilities
themselves do not intrinsically have logging functionality.
The answer is: Alyssa had a capability to a logging facility, and used
The answer is: Alice had a capability to a logging facility, and used
that to do the logging!
But what's interesting about that?
Think about it for a moment: the capability is now doing something more
interesting than mere "proxying".
It isn't merely forwarding or not a message to a single capability...
Alyssa has *composed together* the file capability with the logging
Alice has *composed together* the file capability with the logging
capability.
Pretty cool!
And yet we are about to see an even cooler example of composition.
Now that Alyssa has put enough work into this file, she would like to
Now that Alice has put enough work into this file, she would like to
automatically back up the file's contents twice a day.
Luckily, she has a capability to a job-scheduling service:
: # lets Alyssa schedule work at periodic intervals
: # lets Alice schedule work at periodic intervals
: # aka <JOB-SCHEDULER>
: https://webchronjobs.example/api/3Gw5Ivk_qaNPLWro0MTr_KP1JhuC6GWDvhgDARFG61g
Alyssa also has a capability to a backup service:
Alice also has a capability to a backup service:
: # more or less another place to put files
: # aka <BACKUP-SERVICE>
: https://backups.example/api/BUWRNHd2kIkhl0MvtPUd8tqhW_c99c5KdBZYC7bC0NA
And recall, of course, Alyssa's original capability to <PARTY-FILE>
And recall, of course, Alice's original capability to <PARTY-FILE>
: # aka <PARTY-FILE>
: https://filestore.example/obj/30SVLFRf1cTPNnjgaJfN8r85joIMVDSgWSKXKoYiFuY
Alyssa would like to have =<JOB-SCHEDULER>= periodically copy
Alice would like to have =<JOB-SCHEDULER>= periodically copy
=<PARTY-FILE>= over to =<BACKUP-SERVICE>=.
However, she wouldn't like =<JOB-SCHEDULER>= to be able to read
the contents of =<PARTY-FILE>= or write anything else other than
the backup of =<PARTY-FILE>= to =<BACKUP-SERVICE>=.
This might seem like an impossible task... but Alyssa knows how
This might seem like an impossible task... but Alice knows how
to do it.
Alyssa creates a new object/endpoint on her own server with the
Alice creates a new object/endpoint on her own server with the
following capability URL:
: # aka <BACKUP-PARTY-FILE>
: https://alyssas-home.example/obj/9SzcK9U40-EPYll1ixTU2-jgqvPWJy1xvQWfSp3aT-c
: https://alices-home.example/obj/9SzcK9U40-EPYll1ixTU2-jgqvPWJy1xvQWfSp3aT-c
Now here's the cool thing: internally, =<BACKUP-PARTY-FILE>= knows
about and actually uses both =<PARTY-FILE>= and =<BACKUP-SERVICE>=...
@ -1455,7 +1455,7 @@ But =<BACKUP-PARTY-FILE>= never /discloses/ the locations of either
=<PARTY-FILE>= or =<BACKUP-SERVICE>=.
Why should it?
And so, Alyssa can schedule =<JOB-SCHEDULER>= to run
And so, Alice can schedule =<JOB-SCHEDULER>= to run
=<BACKUP-PARTY-FILE>= twice a day.
But =<JOB-SCHEDULER>= never gets to read the actual contents of
=<PARTY-FILE>= or write anything else to =<BACKUP-SERVICE>=