fep

FEP-2277: ActivityPub core types

Summary

Classification of ActivityPub objects.

Rationale

ActivityPub applications often have different processing rules for actors, activities, collections and other objects. In most cases, the class of an object can be inferred from its context: object delivered to inbox is expected to be an activity, and the value of its actor property is expected to be an actor.

But in some cases the class can not be inferred, for example:

Applications may use the type property to determine object’s class, but that hinders interoperabilty because such applications would not be able to process objects with unknown types. Therefore, a different approach would be preferable.

Core object types

Activity Streams 2.0 standard defines 8 core object types:

The Actor type is also mentioned, but it is not a core type.

Unfortunately, definitions provided in the specification are not precise. The lack of good definitions and the exclusion of the Actor type make standard classification unsuitable for practical purposes. Therefore, applications may need to use a different classification.

One way to divide objects into distinct classes is to look at their properties and their connections to other objects (indicated by their properties). This approach can be used to define 6 core types:

The next section specifies an algorithm that classifies any ActivityPub object as one of these core types by analyzing object’s shape. This technique is often referred to as duck typing.

Duck typing

The following algorithm can be used to determine the core type of the object:

  1. If object has publicKeyPem or publicKeyMultibase property, return VerificationMethod.
  2. If object has href property, return Link.
  3. If object has inbox and outbox properties, return Actor.
  4. If object has actor property, return Activity.
  5. If object has items, orderedItems, totalItems, partOf, first, last, next, prev or current property, return Collection.
  6. Otherwise, return Object.

Application of this algorithm results in non-overlapping core types. For example, an actor with items property is still an actor and not a collection.

The value of type property is not taken into consideration.

[!WARNING] ActivityPub standard requires actors to have both inbox and outbox properties, but in practice outbox is not always present. If compatibility with non-conformant implementations is desirable, step #3 can be changed to “If object has inbox property, return Actor”.

[!WARNING] Pleroma adds an actor property to objects that are not activities. To make an allowance for that, the step #4 of the algorithm can be changed to “If object has an actor property, and doesn’t have an attributedTo property, return Activity”.

Multi-typing

The alternative to duck typing is to use multiple types. For example, this object can be unambiguously identified as an Activity:

{
  "type": ["Bite", "Activity"]
}

However, existing implementations don’t add a second type, and even if changing all of them were possible, duck typing would still need to be used as a fallback during the transitional period.

References

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.

This site is open source. Improve this page.