Which application objects should be ActivityPub actors?


Some applications have many kinds of objects that you may wish to modify, or follow, or be followed by and so on. How to decide, which objects in a web application will be ActivityPub actors, and which won’t be?

What are the best-practice requirements for turning some object into its own actor?

  • The object needs to have its own inbox? (is this ever required?)
  • Needs to have its own list of followers? (for example to allow to follow a specific issue in an issue tracker)
  • The object is conceptually an independent entity not strictly tied to an owner object by definition? For example, an issue/bug is tried to a specific software repo, but the repo itself usually isn’t tied to the user publishing it - a repo can change owner and still it’s the same software; who maintains the repo is a secondary detail

Cons of turning many object types into ActivityPub actors:

  • If the actor needs to POST things (e.g. you follow an issue and the issue delivers a new comment or status update to you), it needs a cryptographic key for signing/verification of HTTP signatures. If you give each actor a separate key, that can mean many thousands of keys. In my implementation I have a little extension that allows actor keys to have instance scope, i.e. a key can sign activities for any actor on that server, and in that case having many actors is a smaller problem. But note that this is a problem only if the actual object needs to deliver stuff; usually objects that are software managed (such as projects, tickets, etc.) don’t actually initiate sending stuff, the actual actions etc. are initiated by the human user actors. And then, those non-human actors such as projects don’t need to have keys.
  • Each actor has its own inbox URI. Unless you use sharedInbox, that means lots of GETs and lots of storage just for the inbox URI of each tiny object. @cwebber said at FOSDEM that sharedInbox was a mistake: Why is that, and is there a good way to avoid GETing/storing the inbox URI of many tiny objects, even if they all use the same URI?
  • Hmmm other cons?

Pros of turning many object types into ActivityPub actors:

  • Activities are POSTed to URIs that correspond to the object being modified, so it’s closer to traditional RESTful APIs, there’s no single inbox URI to which everything is sent. Perhaps this is also good in some security sense? That separate URIs handle changes to separate objects.
  • Objects can be followed using the plain regular Follow activity without any application-specific knowledge. Otherwise, if a project has 1000 issues, each one needs its own followers collection - how would that work? I admit I haven’t thoroughly checked yet.

I guess several points above are about scaling: Some objects are very small and trivially created (say, tickets and comments) while others are more significant entities that usually don’t come by the thousands. So, when considering scaling, and the “conceptually independent” intuition, we could e.g. say, let people and projects be actors, while tickets and smaller things aren’t actors.

That sounds fine and reasonable to me, as long as there’s a good way to handle the following of objects that aren’t actors, for example tickets. I’ll look into that. But for now, I’d love to hear what people think :slight_smile:


Anything that can post an Activity should be an Actor. That implies outbox, and also inbox to support receiving activities addressed to it. The ActivityPub spec denotes the following for Actors:

  • MUST have inbox/outbox
  • SHOULD have following/followers/liked
  • MAY have streams/preferredUsername/endpoints

It also says the following re: Actor types:

ActivityPub actors are generally one of the ActivityStreams Actor Types, but they don’t have to be. For example, a Profile object might be used as an actor, or a type from an ActivityStreams extension.

So if you intend to make an object followable, then it makes sense to create an actor for it. The actor would then post to its outbox and the server would dereference/deliver to the intended audience of followers. It sounds perfectly valid to, say, have an actor of type forgefed:Issue that can be followed. I’ve had similar thoughts about how to theoretically subscribe to a forum/subforum/thread, which would require its own logic about what Follow Object means in the generic sense. What should the object post to its outbox? A list of Updates every time the replies collection is updated? Or more generally any Activity that has object/target referring to itself?