What would ActivityPub look like with capability-based security, anyway?

Why capabilities instead of ACLs?

ActivityPub, like the fediverse in general, is an open world system. Traditional ACLs fail to provide proper scalability to the possibility of 100s of millions of accounts across millions of instances. Object capabilities, on the other hand, are opaque tokens which allow the bearer to possibly consume a set of permissions.

The capability enforcement proposals presently proposed would be deployed as a hybrid approach: capabilities to provide horizontal scalability for the large number of accounts and instances, and deny lists to block specific interactions from actors. The combination of capabilities and deny lists provides for a highly robust permissions system for the fediverse, and mimics previous work on federated open world systems.

Plus, the OcapPub paper on Gitlab:

Unfortunately from a security and social threat perspective, the way
ActivityPub is currently rolled out is under-prepared to protect its
users.
In this paper we introduce OcapPub, which is compatible with the original
ActivityPub specification.
With only mild to mildly-moderate adjustments to the existing network,
we can deliver what we call “networks of consent”: explicit and
intentional connections between different users and entities on the
network.
The idea of “networks of consent” is then implemented on top of a
security paradigm called “object capabilities”, which as we will see
can be neatly mapped on top of the actor model, on which ActivityPub
is based.
While we do not claim that all considerations of consent can be modeled
in this or any protocol, we believe that the maximum of consent that is
possible to encode in such a system can be encoded.