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:

• The object of Update activity can be an object or an actor.
• The object of Announce activity can be an object or an activity.

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:

• Object
• Link
• Activity
• IntransitiveActivity
• Collection
• OrderedCollection
• CollectionPage
• OrderedCollectionPage

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 5 core types:

• Object
• Actor
• Activity
• Collection
• Link

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 href property, return Link.
2. If object has inbox and outbox properties, return Actor.
3. If object has actor property, return Activity.
4. If object has items, orderedItems or totalItems property, return Collection.
5. 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 #1 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 #2 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.

参考文献

• Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018
• James M Snell, Evan Prodromou, Activity Streams 2.0, 2017

著作権

CC0 1.0 ユニバーサル (CC0 1.0) パブリック ドメイン

法律で認められる範囲において、この Fediverse 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。