mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-09-19 14:06:27 +00:00
364 lines
17 KiB
Org Mode
364 lines
17 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
|
|
|
|
[[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
|
|
|
|
As an intermediate step, we should throw out a source of confusion:
|
|
what is "freedom of speech"?
|
|
Does it mean that we have to listen to hate speech?
|
|
|
|
We can start by saying that freedom of speech and the freedom of
|
|
assembly are critical tools.
|
|
Indeed, these are some of the few tools we have against totalitarian
|
|
authorities, of which the world is increasingly threatened by.
|
|
|
|
Nonetheless, we are under severe threat from [[https://en.wikipedia.org/wiki/Neo-fascism][neo-fascists]].
|
|
Neo-fascists play an interesting trick: they exercise their freedom of
|
|
speech by espousing hate speech and, when people say they don't want
|
|
to listen to them, say that this is censorship.
|
|
|
|
Except that freedom of speech merely means that you have the freedom
|
|
to /exercise/ your speech, somewhere.
|
|
It does not mean that everyone has to listen to you.
|
|
You also have the right to call someone an asshole, or stop listening
|
|
to them.
|
|
There is no requirement to read every spam that crosses your email
|
|
inbox to preserve freedom of speech; neither is there to listen to
|
|
someone who is being an asshole.
|
|
The freedom to filter is the complement to freedom of speech.
|
|
This applies to both individuals and to communities.
|
|
|
|
Indeed, neo-fascists are playing a trick: they are not really
|
|
interested in freedom of speech at all.
|
|
They are interested in freedom of /their/ speech, up until the point
|
|
where they can gain enough power to prevent others from saying things
|
|
they don't like.
|
|
This is easily demonstrated; see how many people on the internet are
|
|
willing to threaten women and minorities who exercise the smallest
|
|
amount of autonomy, yet the moment that someone calls them out on
|
|
their /own/ bullshit, they cry censorship.
|
|
Don't confuse an argument for "freeze peach" for an argument for
|
|
"free speech".
|
|
|
|
Still, what can we do?
|
|
Perhaps we cannot prevent assholes from joining the wider social
|
|
network... but maybe we can develop a system where we don't have to
|
|
hear them.
|
|
|
|
** 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 andd
|
|
islikes 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
|
|
|