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
ofUpdate
activity can be an object or an actor. - The
object
ofAnnounce
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:
- If object has
href
property, returnLink
. - If object has
inbox
andoutbox
properties, returnActor
. - If object has
actor
property, returnActivity
. - If object has
items
,orderedItems
ortotalItems
property, returnCollection
. - 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
andoutbox
properties, but in practiceoutbox
is not always present. If compatibility with non-conformant implementations is desirable, step #1 can be changed to "If object hasinbox
property, returnActor
".[!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 anactor
property, and doesn't have anattributedTo
property, returnActivity
".
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 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。