mirror of
https://gitlab.com/spritely/ocappub.git
synced 2025-07-10 19:54:18 +00:00
88 lines
2.6 KiB
Org Mode
88 lines
2.6 KiB
Org Mode
#+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
|
|
|