From 994577bdfdc7c42f07971bf20615c973c0523b50 Mon Sep 17 00:00:00 2001
From: Christopher Lemmer Webber <cwebber@dustycloud.org>
Date: Thu, 27 Feb 2020 19:01:14 -0500
Subject: [PATCH] Added use cases from call, and thanks section

---
 README.org | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/README.org b/README.org
index ca337d0..c036991 100644
--- a/README.org
+++ b/README.org
@@ -1474,7 +1474,74 @@ through argument passing.
 **** Mapping this to ActivityPub
 
 
-*** Spirits, public profiles, private profiles
+*** Spirits, public profiles, direct profiles
+
+** Solving use cases in ActivityPub
+
+TODO: Needs to be cleaned up and incorporated with the above section
+
+*** Simple: sending a direct message
+
+# - sending messages to a specific set of people (not a
+#   group/conversation)
+
+# When we want to send a message to a set of people, we send it to their
+# inbox, the @id of the object is the capability to view the current
+# state of the object (ie, if polling it as opposed to if distributed by
+# an Update activity)
+
+# Difference from first example of ActivityPub spec: id/inbox is
+# unguessable, and also that Alyssa may select a "preferred" inbox for
+# Ben, if she has one (rather than the public/general one)
+
+*** Curating a photo collection
+
+# - creating a photo collection handing out the ability to edit it
+# - using the edit permission
+# - removing the permission on misbehavior
+
+# Need a way in ActivityStreams to share with a user that they've been
+# granted a capability
+
+# When we send the capability, how should the user interface respond?
+
+# Alternative cap: moderating a group of users
+
+# Maybe this isn't a better alternative because talking about moderating
+# a group of users' ability to *write* to the group would either look
+# like an ACL, or involves looking up and revoking specific write
+# capabilities of users... that's too complicated.  Focus on just
+# adding/removing objects from a collection.
+
+# TODO: follow up with cap-talk about the activity that represents a
+# grant of a capability for a specific purpose
+
+*** Rights amplification for reply control
+
+# - being able to control who can reply to a message
+
+# how to revoke cleanly?
+
+# => the unsealer isn't handed directly. Instead, a proxy is passed with
+# the caretaker pattern (can be revoked)
+
+*** Controlling who can send you messages
+
+# - Being able to control who can send messages to you
+
+# => having an inbox for a specific user with accountability +
+# revocation
+
+# => For public profiles, add the proper level of friction (moderator
+# queue, stamps, bayesian or other content-based filter)
+
+*** Managing a mailing-list like Group
+
+# ### Use case number 5: managing a mailing-list like group
+
+# Trickier part isn't who gets messages, but how to revoke write access
+# without introducing an ACL group
+
 
 ** Rights amplification and group-style permissions
 
@@ -1488,4 +1555,21 @@ through argument passing.
 ** Petnames
 
 * Conclusions
+* Thanks
+
+Special thanks to the object capability community as a whole for
+fielding and vetting many relevant ideas to OcapPub.
+Mark Miller in particular gave a large amount of review and encouragement.
+
+David Bruant sat on calls with me and took notes as I rambled my
+thoughts out loud when this document had stalled.
+
+Serge Wroclawski's [[https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md][AP Unwanted Messages]] document preceded and helped
+pave intellectual space for this document, as did our many calls about it.
+
+And of course, thanks to the ActivityPub community and everyone who
+has worked on the specification, implementations, has hosted instances,
+or has enthusiastically used the protocol.
+The federated social web is already exciting; I think it can be even more so.
+I hope this document can help in that direction.