Application actor purpose and limitations

[daenney]

We've recently had an issue opened on GoTosocial about switching bot accounts from the Application actor type that we used, to the service type. This came from Smithereen users, as Smithereen seems to special case the Application actor.

Per the folks that opened the issue:

I am trying to follow a GoToSocial account from my Smithereen instance. However, the actor type of that account is Application, which is unexpected, because as far as I (and @grishka, the author of Smithereen) understand the ActivityStreams spec, this actor type is reserved specifically for client applications. That's why I am unable to follow it: Smithereen just doesn't recognize it as something that can be followed.

Which the author of Smithereen followed-up with:

My idea is that an Application is something that can't be followed and can't produce its own content — which is true for both service actors and client apps. It's something that needs another actor to be useful. I actually use Application objects as my OAuth client IDs. This means that, yes, you can authenticate using a service actor if you really want. I used to have various special-casing for other servers' service actors, but after introducing the API, it has become unnecessary.

In contrast to that, a Service is just an automated Person. It's a complete, self-sufficient actor that can be followed and can produce its own content.

I don't believe this interpretation of the Application actor, and the limitations that are claimed to be inherent to it, are actually the case. The spec says nothing of the sort. In my reading of it, it seems to say quite the opposite:

Actor objects are specializations of the base Object type that represent entities capable of carrying out an Activity. The Activity Vocabulary provides the normative definition of five specific types of Actors: Application | Group | Organization | Person | Service.

This specification intentionally defines Actors in only the most generalized way, stopping short of defining semantically specific properties for each. All Actor objects are specializations of Object and inherit all of the core properties common to all Objects. External vocabularies can be used to express additional detail not covered by the Activity Vocabulary. VCard [ vcard-rdf] SHOULD be used to provide additional metadata for Person, Group, and Organization instances.

The idea of an actor that cannot act seems to not really fit within actor systems and ActivityPub. As I explained in my own follow-up in that issue, I'm reading the Application actor as simply representing the concept of an application. Which could be a valid way to model software on a federating app store, for example.

Since the notion of "some actor type is special and you have to handle it specially" is now getting embedded in some software in the fediverse, I'd like to ask the WG for clarification:

• Is the Application actor meant to represent some entity that cannot be followed?
• Is the Application actor capable of acting on its own?

Or to put it differently, is the Application actor limited in some ways that other actors are not?

[daenney]

There is also https://codeberg.org/fediverse/fep/src/branch/main/fep/2677/fep-2677.md, which somewhat special-cases the Application actor (and is perhaps what folks were referring too when stating that the spec defined it as special.)

[silverpill]

Application actors are widely used, they can represent both client and server software (the latter case is described in FEP-2677 and FEP-d556). These actors may not be followable, but this is an implementer's choice. I am not aware of any limitations that are dictated by the specifications.