fep/fep/2277/fep-2277.md

slug, authors, type, status, discussionsTo, dateReceived, trackingIssue

slug	authors	type	status	discussionsTo	dateReceived	trackingIssue
2277	silverpill <@silverpill@mitra.social>	informational	DRAFT	https://codeberg.org/silverpill/feps/issues	2025-01-31	https://codeberg.org/fediverse/fep/issues/485

FEP-2277: ActivityPub core types

Summary

Classification of ActivityPub objects based on their shape.

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.

However, the class can not always be inferred from context. In some cases, only the object ID is known, such as when it is provided by a user. Embeddings may also be ambiguous:

• 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

Unfortunately, definitions provided in the specification are not precise. Only Object and Link are defined as disjoint types, meaning an object could be an Activity and a Collection at the same time. "Actors" are described as specializations of Object, but there is no corresponding Actor core type.

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

• Actor: an entity that publishes and receives activities.
• Activity: an action taken by an actor.
• Collection: a container for other objects (a collection or a collection page).
• VerificationMethod: a verification method.
• PublicKey: a public key (a legacy form of a verification method).
• Link: a link.
• Object: all other objects.

The next section specifies an algorithm that classifies any ActivityPub object as one of these core types by analyzing the 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 inbox and outbox properties, return Actor.
2. If object has publicKeyMultibase property, return VerificationMethod.
3. If object has publicKeyPem property, return PublicKey.
4. If object has href property, return Link.
5. If object has actor property, return Activity.
6. If object has items, orderedItems, totalItems, partOf, first, last, next, prev or current property, return Collection.
7. 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 #5 of the algorithm can be changed to "If object has an actor property, and doesn't have an attributedTo property, return Activity".

JSON-LD

The output of the algorithm might be different in LD-aware and in LD-unaware applications due to a possibility of re-mapping of terms in @context.

This may pose a security risk.

Example:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "foo": "as:inbox",
      "bar": "as:outbox"
    }
  ],
  "type": "Note",
  "id": "https://social.example/note",
  "foo": "https://social.example/inbox",
  "bar": "https://social.example/outbox"
}

Alternatives considered

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.

Type hierachies

The core type of an object can be determined via the definition of its type in a vocabulary, but that means all ActivityPub applications would have to support JSON-LD.

References

• Christine Lemmer-Webber, Jessica Tallon, Erin Shepherd, Amy Guy, Evan Prodromou, ActivityPub, 2018
• James M Snell, Evan Prodromou, Activity Streams 2.0, 2017

Copyright

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.