What is an Actor, anyway...

This is a spin-off discussion from today's ForumWG meeting

During today's ForumWG meeting an interesting side discussion cropped up regarding what constitutes an Actor, and whether other object types could be considered Actor-like.

ActivityStreams defines an Actor as being one of five types:

  • Application
  • Group
  • Organization
  • Person
  • Service

However, a looser definition of an Actor could simply be "if the resolved object contains an inbox and an outbox".

Such a definition opens up the possibility of having lots of things be followable, perhaps without direct user interaction. This was one possibility outlined by @cpmoser@mastodon.social

@trwnh@mastodon.social also mentioned that Mastodon does not consider an object as being an actor unless it is one of those five types.

@dmitri@social.coop noted that this was a topic brought up at a previous AP issue triage meeting. Could you provide a summary?

Also cc @evan@cosocial.ca for his thoughts.

@julian From ActivityPub spec:

>ActivityPub actors are generally one of the ActivityStreams Actor Types, but they don't have to be.

The looser definition is correct.

@julian @cpmoser @trwnh @dmitri absolutely. The ActivityPub spec says anything can be an actor. It just has to have the required properties.

@julian @cpmoser @trwnh @dmitri also, sorry I missed the call!

@julian @cpmoser @trwnh @dmitri HOWEVER, Mastodon currently only allows the big five. There should probably be a ticket for that somewhere.

@silverpill @julian

Though they are different beasts I continue to be intrigued by alignments in codebase and architecture of actor model with the actor-based nature of AP.


@silverpill @julian

Though they are different beasts I continue to be intrigued by alignments in codebase and architecture of actor model with the actor-based nature of AP. Posted some musings before, inspired by @hrefna



To answer the question: The standard that I have been told is that "anything can be an actor without declaring it, it just needs an inbox and outbox."

I think this is a terrible pattern, personally, but that's the standard.

@silverpill @julian

@evan @julian @cpmoser @dmitri


What would work for Mastodon is to multi-type the actor as one of the five types, so you could do [Group, Collection] or [Service, Collection] but not just [Collection]

But yeah, I think the restriction should be dropped.

1 Like

The AS2 Recommendation defines actors as “entities capable of carrying out an Activity” and (for the Application actor property) “[describing] one or more entities that either performed or are expected to perform the activity”. One can infer that any Object referenced or Link’ed to by the actor property of an Activity type is an actor that “carried out (or performed) the activity”.

The ActivityPub Recommendation added additional requirements for an actor to have inbox and outbox endpoints. (However, the inverse isn’t necessarily true. An object with an inbox and outbox endpoint may or may not be an AP actor.)

From my perspective this means there are AS2 actors and there are AP actors. The former have no inbox/outbox requirement. The AP actors are a constrained variant of AS2 actors. An application can have both kind of actors. Obviously, the AS2-only actors cannot communicate using AP inboxes, but they may still be useful, in general, for modeling “entities capable of carrying out an Activity”.

I’m not making any claims about well this would interoperate given how the existing AP implementations have evolved. Most current applications are hard-coded to a very restricted subset of AS2 types and often make actor-related assumptions that are not part of the AS2/AP Recommendations.

In practice, beyond the 5 core actor “types” in AS2, identifying actor and extended actor types seems to me to be very application-specific.