More consistently call Alice/Bob Alyssa/Ben

This converges on the ActivityPub document

README.org

@@ -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.
+a protocol perspective, there is no guarantee that Ben will comply.
-However this does not mean there are no consequences for Bob if he
+However this does not mean there are no consequences for Ben if he
-betrays Alice's trust: Alice may stop being his friend, or at least
+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
+If Alyssa tells Ben that Ben, and Ben alone, has been granted access to
-this tool, we should realize that as long as Bob wants to cooperate
+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
+a proxy that can forward requests to Alyssa's tool as if they were
-Bob's.
+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
+Still, there is something we can do: we could wrap Ben's access to
-Alice's tool in such a way that it logs that this is the capability
+Alyssa'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
+Alyssa handed to Ben being invoked every time it is invoked, and
-disable access if it is misused... whether due to Bob's actions,
+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
+In this way, even though Alyssa cannot prevent Ben from delegating
-authority, Alice can hold Bob accountable for the authority granted
+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
+Those mailing lists may be all on different servers, and yet Alyssa
-is able to be the right version of Alice for each of those communities
+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
+If Alyssa does not yet know or trust Ben, it is up to Alyssa's default
-settings as to whether or not Bob has any opportunity to message Alice.
+settings as to whether or not Ben has any opportunity to message Alyssa.
-Maybe Alice only gets messages from entities she has existing
+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
+Now Ben has to "pay" Alyssa to be spammed (and depending on how we
-decide to implement it, Alice might be able to keep this payment).
+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
+ - *revocation*: Let's say that Alyssa wants to allow her roommate
-   Bob to drive her car, but she also wants to be able to take away
+   Ben 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.
+   that right if Ben misuses it or if they stop being roommates.
-   Alice can make a new car key that has a wire inside of it;
+   Alyssa 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
+   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).
+   else Ben has delegated a key to).
- - *accountability*: Alice has multiple roommates, and while she would
+ - *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
+   console (which only Alyssa has access to) takes note of the associated
-   name, so Alice can check who left a mess last.
+   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
+If Alyssa knows Ben and Alyssa knows Carol, Alyssa might decide it is
-useful to introduce Bob to Carol.
+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
+number exchange... "Alyssa is sending Ben the message =foo=, which
-contains a reference to Carol, and now Bob has been introduced to /
+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.
+Carol hears of Ben's ability to append guests and is jealous.
-She calls up Alice and says, can't I get access to =APPEND= also?
+She calls up Alyssa and says, can't I get access to =APPEND= also?
-Alice trusts Bob to keep the number of guests he added within reason
+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.