View source for ActivityPub errata/Details

Errata for [https://www.w3.org/TR/activitypub/ ActivityPub].

== Needs errata ==

* 6.3.1 Partial Updates is incompatible with JSON-LD handling of <code>null</code> values [https://github.com/w3c/activitypub/issues/396#issuecomment-1802316358 GitHub issue]

* Various examples use <code>Public</code> or <code>https://www.w3.org/ns/activitystreams#Public</code>, which are not consistent with JSON-LD compacted form <code>as:Public</code> [https://github.com/w3c/activitypub/issues/404#issuecomment-2048003913 GitHub issue]

* Possible non-normative note clarifying S2S Add/Remove and side effects: [https://github.com/w3c/activitypub/issues/407 GitHub issue]

* Lowercase "should" SHOULD be replaced with other wording to avoid confusion with normative "SHOULD" [https://github.com/w3c/activitypub/issues/412#issuecomment-1919626978 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 <code>inbox</code> collection ===

[https://github.com/w3c/activitypub/issues/289#issuecomment-1533281501 GitHub issue]

In section 4.1 "Actor objects", the definition of <code>inbox</code> currently reads:

<blockquote>
'''A reference to''' an ActivityStreams OrderedCollection [...]
</blockquote>

It should instead read with parallel structure to the definition of <code>outbox</code>:

<blockquote>
An ActivityStreams OrderedCollection [...]
</blockquote>

Furthermore, examples or non-normative notes should clarify that both references and embedded representations are allowed. 

=== Fix definition of <code>followers</code> collection ===

[https://github.com/w3c/activitypub/issues/320#issuecomment-2183105050 GitHub issue]

In [https://www.w3.org/TR/activitypub/#followers Section 5.3 "Followers collection"], current text reads:

<blockquote>
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.
</blockquote>

It should instead read:

<blockquote>
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.
</blockquote>

=== Fix wording for inbox forwarding to specify that the activity is being forwarded, not the object ===

[https://github.com/w3c/activitypub/issues/441#issuecomment-2129939099 GitHub issue]

In [https://www.w3.org/TR/activitypub/#inbox-forwarding Section 7.1.2 "Forwarding from Inbox"], current text reads:

<blockquote>
The server MUST only target the values of to, cc, and/or audience on the original '''object''' being forwarded
</blockquote>

It should instead read:

<blockquote>
The server MUST only target the values of to, cc, and/or audience on the original '''activity''' being forwarded
</blockquote>

=== Fix wording for the side effect of receiving a Follow activity in the inbox  ===

[https://github.com/w3c/activitypub/issues/320#issuecomment-2183105050 GitHub issue]

In [https://www.w3.org/TR/activitypub/#follow-activity-inbox Section 7.5 "Follow Activity"], current text reads:

<blockquote>
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.
</blockquote>

It should instead read:

<blockquote>
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.
</blockquote>

== Resolved ==

=== Remove mention of <code>preferredUsername</code> as a natural language property ===

[https://github.com/w3c/activitypub/issues/395#issuecomment-1779587928 GitHub issue]

[https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-395 SWICG resolution]

The [https://www.w3.org/TR/activitypub/#h-note-2 note at the end of Section 4.1 "Actor objects"] currently incorrectly refers to <code>preferredUsername</code> as a natural language property.

It should read:

<blockquote>
Properties containing natural language values, such as name<del>, preferredUsername,</del> or summary, make use of natural language support defined in ActivityStreams.
</blockquote>

=== Clarify that the "reverse chronological order" requirement only applies to <code>OrderedCollection</code> properties defined in ActivityPub, not to all <code>OrderedCollection</code> entities ===

[https://github.com/w3c/activitypub/issues/376#issuecomment-1611715348 GitHub issue]

[https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-376 SWICG resolution]

In [https://www.w3.org/TR/activitypub/#collections Section 5 "Collections"], current text reads:

<blockquote>
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.'''
</blockquote>

It should instead read:

<blockquote>
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.'''
</blockquote>

=== Fix description of the <code>liked</code> collection in a non-normative clarifying note ===

[https://github.com/w3c/activitypub/issues/317#issuecomment-2129978604 GitHub issue]

[https://github.com/swicg/meetings/blob/main/2024-08-02/README.md#httpsgithubcomw3cactivitypubissues317-errata SWICG resolution]

In [https://www.w3.org/TR/activitypub/#h-note-6 the note at the end of Section 5.7 "Likes Collection"], current text reads:

<blockquote>
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.
</blockquote>

It should instead read:

<blockquote>
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.
</blockquote>

=== Allow servers to filter delivery when activities are received in the outbox ===

[https://github.com/w3c/activitypub/issues/297#issuecomment-1632804209 GitHub issue]

[https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-297 SWICG resolution]

==== [https://www.w3.org/TR/activitypub/#client-to-server-outbox-delivery Section 6.11 "Delivery"] ====

Current text reads:

<blockquote>
Federated servers '''MUST''' perform delivery on all Activities posted to the outbox according to outbox delivery.
</blockquote>

It should instead read:

<blockquote>
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.'''
</blockquote>

==== [https://www.w3.org/TR/activitypub/#outbox-delivery Section 7.1.1 "Outbox Delivery Requirements for Server to Server"] ====

Current text reads:

<blockquote>
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.
</blockquote>

It should instead read:

<blockquote>
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.'''
</blockquote>

== 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]