2019-07-16 18:49:39 +00:00
|
|
|
#+TITLE: OcapPub: Towards networks of consent
|
|
|
|
#+AUTHOR: Christopher Lemmer Webber
|
|
|
|
|
2019-07-16 18:52:37 +00:00
|
|
|
/This paper released under the Apache License version 2.0; see [[file:./LICENSE.txt][LICENSE.txt]] for details./
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
* Conceptual overview
|
|
|
|
|
|
|
|
** ActivityPub
|
|
|
|
|
2019-07-17 15:38:49 +00:00
|
|
|
# - 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
|
|
|
|
# - 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.
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
** The mess we're in
|
|
|
|
|
2019-07-17 15:38:49 +00:00
|
|
|
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
** Don't pretend we can prevent what we can't
|
|
|
|
|
2019-07-16 19:17:15 +00:00
|
|
|
** Freedom of speech also means freedom to filter
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
** 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)
|
|
|
|
|
2019-07-17 15:38:49 +00:00
|
|
|
# -
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
*** Ocaps meet ActivityPub objects/actors
|
|
|
|
|
2019-07-17 15:38:49 +00:00
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
** True names, public profiles, private profiles
|
|
|
|
|
|
|
|
** Accountability and revocation in an ocap system
|
|
|
|
|
|
|
|
** Rights amplification and group-style permissions
|
|
|
|
|
2019-07-17 15:38:49 +00:00
|
|
|
** multiBox vs sharedInbox
|
|
|
|
|
2019-07-16 19:03:13 +00:00
|
|
|
* Limitations
|
|
|
|
|
2019-07-16 18:49:39 +00:00
|
|
|
* Future work
|
|
|
|
** Petnames
|
|
|
|
|
|
|
|
* Conclusions
|
2019-07-16 18:52:37 +00:00
|
|
|
|