ActivityPub errata
Errata for ActivityPub.
Needs errata
- 6.3.1 Partial Updates is incompatible with JSON-LD handling of
nullvalues GitHub issue
- Various examples use
Publicorhttps://www.w3.org/ns/activitystreams#Public, which are not consistent with JSON-LD compacted formas:PublicGitHub issue
- Possible non-normative note clarifying S2S Add/Remove and side effects: GitHub issue
- Lowercase "should" SHOULD be replaced with other wording to avoid confusion with normative "SHOULD" GitHub issue
- evanp notes: "This seems like a big task. At worst, we're looking at about 83 ERRATA.md entries for text."
- nightpool notes: "I could see the benefit of addressing this in the editor's draft if we're working towards a new TR update, but I don't think it's worth errata, they would just be too numerous to be helpful."
Proposed
Clarify the definition of the inbox collection
In section 4.1 "Actor objects", the definition of inbox currently reads:
A reference to an ActivityStreams OrderedCollection [...]
It should instead read with parallel structure to the definition of outbox:
An ActivityStreams OrderedCollection [...]
Furthermore, examples or non-normative notes should clarify that both references and embedded representations are allowed.
Fix definition of followers collection
In Section 5.3 "Followers collection", current text reads:
Every actor SHOULD have a followers collection. This is a list of everyone who has sent a Follow activity for the actor, added as a side effect. This is where one would find a list of all the actors that are following the actor.
It should instead read:
Every actor SHOULD have a followers collection. This is a list of everyone who has sent a Follow activity for the actor that has been accepted, added as a side effect of the Accept. This is where one would find a list of all the actors that are following the actor.
Fix description of the liked collection in a non-normative clarifying note
In the note at the end of Section 5.7 "Likes Collection", current text reads:
liked: Specifically a property of actors. This is a collection of Like activities performed by the actor, added to the collection as a side effect of delivery to the outbox.
It should instead read:
liked: Specifically a property of actors. This is a collection of objects liked by the actor, added to the collection as a side effect of delivery to the outbox.
Fix wording for inbox forwarding to specify that the activity is being forwarded, not the object
In Section 7.1.2 "Forwarding from Inbox", current text reads:
The server MUST only target the values of to, cc, and/or audience on the original object being forwarded
It should instead read:
The server MUST only target the values of to, cc, and/or audience on the original activity being forwarded
Fix wording for the side effect of receiving a Follow activity in the inbox
In Section 7.5 "Follow Activity", current text reads:
The side effect of receiving this in an inbox is that the server SHOULD generate either an Accept or Reject activity with the Follow as the object and deliver it to the actor of the Follow. The Accept or Reject MAY be generated automatically, or MAY be the result of user input (possibly after some delay in which the user reviews). Servers MAY choose to not explicitly send a Reject in response to a Follow, though implementors ought to be aware that the server sending the request could be left in an intermediate state. For example, a server might not send a Reject to protect a user's privacy.
In the case of receiving an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection.
It should instead read:
The side effect of receiving this in an inbox is that the server SHOULD generate either an Accept or Reject activity with the Follow as the object and deliver it to the actor of the Follow. The Accept or Reject MAY be generated automatically, or MAY be the result of user input (possibly after some delay in which the user reviews). Servers MAY choose to not explicitly send a Reject in response to a Follow, though implementors ought to be aware that the server sending the request could be left in an intermediate state. For example, a server might not send a Reject to protect a user's privacy.
In the case of generating and delivering an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection.
Resolved
Remove mention of preferredUsername as a natural language property
The note at the end of Section 4.1 "Actor objects" currently incorrectly refers to preferredUsername as a natural language property.
It should read:
Properties containing natural language values, such as name
, preferredUsername,or summary, make use of natural language support defined in ActivityStreams.
Clarify that the "reverse chronological order" requirement only applies to OrderedCollection properties defined in ActivityPub, not to all OrderedCollection entities
In Section 5 "Collections", current text reads:
Note that some of these collections are specified to be of type OrderedCollection specifically, while others are permitted to be either a Collection or an OrderedCollection. An OrderedCollection MUST be presented consistently in reverse chronological order.
It should instead read:
Note that some of these collections are specified to be of type OrderedCollection specifically, while others are permitted to be either a Collection or an OrderedCollection. These OrderedCollection objects MUST be ordered consistently in reverse chronological order. Collections defined in other vocabularies, including extensions, are not subject to this requirement and can be unordered or ordered by other criteria.
Allow servers to filter delivery when activities are received in the outbox
Section 6.11 "Delivery"
Current text reads:
Federated servers MUST perform delivery on all Activities posted to the outbox according to outbox delivery.
It should instead read:
Federated servers SHOULD perform delivery on all Activities posted to the outbox according to outbox delivery. Servers MAY filter activities for privacy, abuse mitigation, or other reasons.
Section 7.1.1 "Outbox Delivery Requirements for Server to Server"
Current text reads:
When objects are received in the outbox (for servers which support both Client to Server interactions and Server to Server Interactions), the server MUST target and deliver to:
- The to, bto, cc, bcc or audience fields if their values are individuals or Collections owned by the actor.
These fields will have been populated appropriately by the client which posted the Activity to the outbox.
It should instead read:
When objects are received in the outbox (for servers which support both Client to Server interactions and Server to Server Interactions), the server SHOULD target and deliver to:
- The to, bto, cc, bcc or audience fields if their values are individuals or Collections owned by the actor.
These fields will have been populated appropriately by the client which posted the Activity to the outbox.
Servers MAY filter activities for privacy, abuse mitigation, or other reasons.
Incorporated into editor's draft
[Link to GitHub PRs here when they are made? Or otherwise keep track of editor's draft changes and changelog somehow]