mirrors/fep
1
0
Fork 0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-08 13:35:51 +00:00
Code Packages Wiki Activity

FEP-2277: Actor and PublicKey (#708)

Browse Source 
- Raised priority of `Actor` core type.
- Added `PublicKey` core type.
- Expanded "Rationale" section.
- Improved wording in the paragraph about downsides of standard types.
- Clarified definition of `Collection`.
- Added "Type hierachies" section.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/708
Co-authored-by: silverpill <silverpill@firemail.cc>
Co-committed-by: silverpill <silverpill@firemail.cc>
This commit is contained in:
silverpill
2025-10-30 18:35:39 +01:00
committed by silverpill
parent 91a23df063
commit 1a04842f13
1 changed files with 23 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/2277/fep-2277.md
+23 -14
View File
@@ -17,7 +17,7 @@ Classification of [ActivityPub] objects based on their shape.
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:
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.
@@ -37,41 +37,43 @@ Applications may use the `type` property to determine object's class, but that h
- `CollectionPage`
- `OrderedCollectionPage`
The `Actor` type is also mentioned, but it is not a core type.
Unfortunately, definitions provided in the specification are not precise. Only `Object` and `Link` are defined as [disjoint types](https://github.com/w3c/activitystreams/issues/641), 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.
Unfortunately, definitions provided in the specification are not precise. Only `Object` and `Link` are defined as [disjoint types](https://github.com/w3c/activitystreams/issues/641), meaning an object could be an `Activity` and a `Collection` at the same time. 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.
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:
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.
- `VerificationMethod`: a public key.
- `Collection`: a container for other objects (a collection or a collection page).
- `VerificationMethod`: a [verification method][VerificationMethod].
- `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][DuckTyping].
### 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`.
1. If object has `href` property, return `Link`.
1. If object has `inbox` and `outbox` properties, return `Actor`.
1. If object has `actor` property, return `Activity`.
1. If object has `items`, `orderedItems`, `totalItems`, `partOf`, `first`, `last`, `next`, `prev` or `current` property, return `Collection`.
1. Otherwise, return `Object`.
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 #3 can be changed to "If object has `inbox` property, return `Actor`".
>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](https://git.pleroma.social/pleroma/pleroma/-/issues/3269). 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`".
>Pleroma [adds an `actor` property to objects that are not activities](https://git.pleroma.social/pleroma/pleroma/-/issues/3269). 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
@@ -97,6 +99,8 @@ Example:
}
```
## 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`:
@@ -109,6 +113,10 @@ The alternative to duck typing is to use multiple types. For example, this objec
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
@@ -118,6 +126,7 @@ However, existing implementations don't add a second type, and even if changing
[ActivityStreams]: https://www.w3.org/TR/activitystreams-core/
[ActivityStreams-Model]: https://www.w3.org/TR/activitystreams-core/#model
[DuckTyping]: https://en.wikipedia.org/wiki/Duck_typing
[VerificationMethod]: https://www.w3.org/TR/cid/#verification-methods
## Copyright