#+TITLE: OcapPub: Towards networks of consent
#+AUTHOR: Christopher Lemmer Webber

/This paper released under the Apache License version 2.0; see [[file:./LICENSE.txt][LICENSE.txt]] for details./

/For a broader overview of various anti-spam techniques, see [[https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md][AP Unwanted Messages]], which is in many ways informed this document but currently differs in some implementation rollout differs.  (These two documents may converge.) */

* Conceptual overview

** ActivityPub

# - ActivityPub is an actor model protocol.
# - The general design can be understood from the overview section of the spec

# - In general, most of the design of ActivityPub is fairly clean, with
#   a few exceptions

#   - sharedInbox is a break from the actor model protocol and was a late
#     addition
#   - authentication is not specified.  The community has settled
#     on using http signatures for signing requests, though there is no
#     "clean agreement" on how to attach signatures *to* posts yet.
#   - authorization is not specified
#   - (json-ld conversations outside of the scope of this particular post)

# - What to do about the holes in the spec?  Many community members have
#   asked that we codify current behavior.  However, as this document lays
#   out, some of the ways those holes were filled may be causing problems
#   and we may want to consider how to best redirect them without throwing
#   out the network as it has been deployed.

# - Nonetheless, ActivityPub has achieved major adoption.  ActivityPub
#   has the good fortune that its earliest adopters were frequently
#   people who are actively concerned with human rights and the
#   well-being of marginalized groups.

** The mess we're in




** Don't pretend we can prevent what we can't

** Freedom of speech also means freedom to filter

** Anti-solutions

(Note that things in the anti-solutions category aren't necessarily
"things that aren't useful", but rather "things that end up causing
problems if they're the foundation".)

*** Blocklists, allow-lists, and perimeter security

*** Access Control Lists

*** Content-centric filtering

*** Reputation scoring

*** Going back to centralization

** A way forward: networks of consent

** Must we boil the ocean?

* Key concepts
** Object capabilities (ocaps)

# - 

*** Ocaps meet ActivityPub objects/actors


** True names, public profiles, private profiles

** Accountability and revocation in an ocap system

** Rights amplification and group-style permissions

** multiBox vs sharedInbox

* Limitations

* Future work
** Petnames

* Conclusions