ocappub/README.org

#+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

[[https://www.w3.org/TR/activitypub/][ActivityPub]] is a federated social network protocol.
It is generally fairly easily understood by reading the
[[https://en.wikipedia.org/wiki/Actor_model][Overview section of the standard]].
In short, just as anyone can host their own email server, anyone can
host their own ActivityPub server, and yet different users on different
servers can interact.
At the time of writing, ActivityPub is seeing major uptake, with
several thousand nodes and several million registered users (with the
caveat that registered users is not the same as active users).
The wider network of ActivityPub-using programs is often called
"the fediverse" (though this term predates ActivityPub, and was
also used to describe adoption of its predecessor, OStatus).

ActivityPub defines both a client-to-server and server-to-server
protocol, but at this time the server-to-server protocol is what is
most popular and is the primary concern of this article.

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

ActivityPub's core design is fairly clean, following the
[[https://en.wikipedia.org/wiki/Actor_model#Fundamental_concepts][actor model]].
Different entities on the network can create other actors/objects
(such as someone writing a note) and communicate via message passing.
A core set of behaviors are defined in the spec for common message
types, but the system is extensible so that implementations may define
new terms with minimal ambiguity.
If two instances both understand the same terms, they may be able to
operate using behaviors not defined in the original protocol.
This is called an "open world assumption" and is necessary for a
protocol as general as ActivityPub; it would be extremely egotistical
of the ActivityPub authors to assume that we could predict all future
needs of users.[fn:json-ld]

#   - (json-ld conversations outside of the scope of this particular post)

Unfortunately (mostly due to time constraints and lack of consensus),
even though most of what is defined in ActivityPub is fairly
clean/simple, ActivityPub needed to be released with "holes in the
spec".
Certain key aspects critical to a functioning ActivityPub server are
not specified:

#   - 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

 - Authentication is not specified.  Authentication is important to
   verify "did this entity really say this thing".[fn:did-you-say-it]
   However, the community has mostly converged on using [[https://tools.ietf.org/html/draft-cavage-http-signatures-11][HTTP Signatures]]
   to sign requests when delivering posts to other users.
   The advantage of HTTP Signatures is that they are extremely simple
   to implement and require no normalization of message structure;
   simply sign the body (and some headers) as-you-are-sending-it.
   The disadvantage of HTTP Signatures is that this signature does
   not "stick" to the original post and so cannot be "carried around"
   the network.
   A minority of implementations have implemented some early versions
   of [[https://w3c-dvcg.github.io/ld-proofs/][Linked Data Proofs]] (formerly known as "Lined Data Signatures"),
   however this requires access to a normalization algorithm that not
   all users have a library for in their language, so Linked Data Proofs
   have not as of yet caught on as popularly as HTTP Signatures.

 - Authorization is also not specified.  (Authentication and
   authorization are frequently confused (especially because in
   English, the words are so similar) but mean two very different
   things: the former is checking who said/did a thing, the latter is
   checking whether they are allowed to do a thing.)  As of right now,
   authorization tends to be extremely ad-hoc in ActivityPub systems,
   sometimes as ad-hoc as unspecified heuristics from tracking who
   received messages previously, who sent a message the first time,
   and so on.  The primary way this is worked around is sadly that
   interactions which require richer authorization simply have not
   been rolled out onto the ActivityPub network.

Compounding this situation is the general confusion/belief that
autorization must stem from authentication.
This document aims to show that not only is this not true, it is also
a dangerous assumption with unintended consequences.
An alternative approach based on "object capabilities" is
demonstrated, showing that the actor model itself, if we take it at
its purest form, is itself already a sufficient authorization system.

#   - sharedInbox is a break from the actor model protocol and was a late
#     addition

Unfortunately there is a complication.
At the last minute of ActivityPub's standardization, =sharedInbox= was
added as a form of mutated behavior from the previously described
=publicInbox= (which was a place for servers to share public content).
The motivation of =sharedInbox= is admirable: while ActivityPub is based
on explicit message sending to actors' =inbox= endpoints, if an actor
on server A needs to send a message to 1000 followers on server B,
why should server A make 1000 separate requests when it could do it
in one?
A good point, but the primary mistake in how this one request is made;
rather than sending one message with a listing of all 1000 recipients
on that server (which would preserve the actor model integrity),
it was advocated that servers are already tracking follower information,
so the receiving server can decide whom to send the message to.
Unfortunately this decision breaks the actor model and also our suggested
solution to authorization; see [[https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md#org7937fed][MultiBox]] for a suggestion on how we
can solve this.

# - 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.

Despite these issues, ActivityPub has achieved major adoption.
ActivityPub has the good fortune that its earliest adopters tended to
be people who cared about human rights and the needs of marginalized
groups, and spam has been relatively minimal.

[fn:json-ld] The technology that ActivityPub uses to accomplish this is
  called [[https://json-ld.org/][json-ld]] and admittedly has been one of the most controvercial
  decisions in the ActivityPub specification.
  Most of the objections have surrounded the unavailability of json-ld
  libraries in some languages or the difficulty of mapping an open-world
  assumption onto strongly typed systems without an "other data" bucket.
  Since a project like ActivityPub must allow for the possibility of
  extensions, we cannot escape open-world assumptions.
  However, there may be things that can be done to improve happiness
  about what extension mechanism is used; these discussions are out of
  scope for this particular document, however.

[fn:did-you-say-it] Or more accurately, since users may appoint
  someone else to manage posting for them, "was this post really made
  by someone who is authorized to speak on behalf of this entity".

** The mess we're in

# - "there are no nazis on the fediverse"

#+BEGIN_QUOTE
  [[https://www.vice.com/en_us/article/783akg/mastodon-is-like-twitter-without-nazis-so-why-are-we-not-using-it][Mastodon Is Like Twitter Without Nazis, So Why Are We Not Using It?]]
   -- Article by Sarah Jeong, which drove much interest in
      adoption of Mastodon and the surrounding "fediverse"
#+END_QUOTE

At the time this article was written about Mastodon (by far the most
popular implementation of ActivityPub, and also largely responsible
for driving interest in the protocol amongst other projects), its
premise was semi-true; while it wasn't that there were no neo-nazis on
the fediverse, the primary group which had driven recent adoption were
themselves marginalized groups who felt betrayed by ther larger
centralized social networks.
They decided it was time for them to make homes for themselves.
The article participated in an ongoing narrative that (from the
author's perspective) helped reinforce these community norms for the
better.

However, there nothing about Mastodon or the fediverse at large
(including the core of ActivityPub) /specifically/ prevented nazis or
other entities conveying undesirable messages (including spam) from
entering the network; they just weren't there or were in small enough
numbers that instance administrators could block them.
However, the fediverse no longer has the luxury of
[[https://www.vice.com/en_us/article/mb8y3x/the-nazi-free-alternative-to-twitter-is-now-home-to-the-biggest-far-right-social-network][claiming to be neo-nazi free]] (if it ever could).
The risk that people from marginalized groups, which the fediverse has
in recent history appealed to, are now at risk from targeted harassment
from these groups.
Even untargeted messages, such as general hate speech, may have a
severe negative impact on one's well being.
Spam, likewise, is an increasing topic of administrators and
implementors (as it has historically been for other federated social
protocols, such as email/SMTP and OStatus during its heyday).
It appears that the same nature of decentralized social networks in
allowing marginalized communities to make communities for themselves
also means that harassment, hate speech, and spam are not possible
to wholly eject from the system.

Must all good things come to an end?

** Unwanted messages, from spam to harassment

One thing that spam and harassment have in common is that they are the
delivery of messages that are not desired by their recipient.
However, it would be a mistake to claim that the impact of the two are
the same: spam is an annoyance, and mostly wastes time.
Harassment wastes time, but may also cause trauma.

Nonetheless, despite the impact of spam and harassment being very
different, the solutions are likely very similar.
Unwanted messages tend to come from unwanted social connections.
If the problem is users receiving unwanted messages, perhaps the
solution comes in making intentional social connections.
But how can we get from here to there?

** Freedom of speech also means freedom to filter


** Did we borrow the wrong assumptions?

#+BEGIN_QUOTE
  "What if we're making the wrong assumptions about our social networks?
  What if we're focusing on breadth, when we really should be focusing
  on depth?"
    -- from a conversation with Evan Prodromou, initial designer of
       both ActivityPub and OStatus' protcol designs
#+END_QUOTE

What is Evan trying to say here?
Most contemporary social networks are run by surveillance capitalist
organizations; in other words, their business model is based on as much
"attention" as possible as they can sell to advertisers.
Whether or not capitalism is a problem is left as an exercise for the
reader, but hopefully most readers will agree that a business model
based on destroying privacy can lead to undesirable outcomes.
One such undesirable outcome is that these companies subtly affect the
way people interact with each other not dependent on what is
healthiest for people and their social relationships, but based on what
will generate the most advertising revenue.

One egregious example of this is the prominence of the "follower
count" in contemporary social networks, particularly Twitter.
When visiting another user's profile, even someone who is aware of and
dislikes its effect will have trouble not comparing follower counts
and mentally using this as a value judgement, either about the other
person or about themselves.
Users are subconsciously tricked into playing a popularity contest,
whether they want to play that game or not.
Rather than being encouraged to develop a network of meaningful
relationships with which they have meaningful communications, users
face a subconscious pressure to tailor their messaging and even who
else they follow to maximize their follower count.

So why on earth would we see follower counts also appear prominently
on the federated social web, if these tools are generally built by
teams that do not benefit from the same advertising structure?
The answer is simple: it is what developers and users are both
familiar with.
This is not an accusation; in fact, it is a highly sympathetic
position to take: the cost, for developers and users alike, of
developing a system is lower by going with the familiar rather than
researching the ideal.
But the consequences may nonetheless be severe.

So it is too with how we build our notion of security and
authorization, which developers tend to mimic from the systems they
have already seen.
Why wouldn't they?
But it may be that these patterns are, in fact, anti-patterns.
it may be time for some re-evaluation.

# - social networks: breadth vs depth?
#   - wholesale borrowing of surveillance capitalist assumptions

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

# - introduce ocap community phrase
# - introduce revised version

# - "the fediverse is not indexed"

# 


** 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