ocappub/README.org

OcapPub: Towards networks of consent

• Conceptual overview
  • ActivityPub
  • Unwanted messages, from spam to harassment
  • Freedom of speech also means freedom to filter
  • Don't pretend we can prevent what we can't
  • Anti-solutions
    • 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

This paper released under the Apache License version 2.0; see LICENSE.txt for details.

For a broader overview of various anti-spam techniques, see 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 a federated social network protocol. It is generally fairly easily understood by reading the 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). 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.

ActivityPub's core design is fairly clean, following the 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.¹

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. Authentication is important to verify "did this entity really say this thing".² However, the community has mostly converged on using 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 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.

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 MultiBox for a suggestion on how we can solve this.

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.

Unwanted messages, from spam to harassment

Freedom of speech also means freedom to filter

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

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

---

¹

The technology that ActivityPub uses to accomplish this is called 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.

²

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