ActivityPub errata/Proposed

In section 7.1.2 "Forwarding from Inbox" the sentence The server MUST only target the values of to, cc, and/or audience on the original object being forwarded should read The server MUST only target the values of to, cc, and/or audience on the original activity being forwarded.
In Examples 6, 10, 15, 16 the public collection address should be compacted to "as:Public".
The Note in section 5.6 "Public Addressing" should read Compacting an ActivityStreams object using the ActivityStreams JSON-LD context will result in "https://www.w3.org/ns/activitystreams#Public" being represented as "as:Public". Publishers might erroneously produce representations with the full URI or with the unprefixed value "Public". To maximize interoperability, consumers can accept all three representations.
Section 3.1, "Object identifiers", should read in part: However, for client to server communication, a server receiving an object posted to the outbox with no specified id SHOULD allocate an object ID and attach it to the posted object.
Section 3.1 "Object identifiers", first paragraph, should read in part: ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient or anonymous, in which case the identifier MAY be omitted. The identifiers must be a publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).
In Section 6.3.1 "Partial updates", the following sentence should be deleted: A special exception is for when the value is the json null type; this means that this field should be removed from the server's representation of the object.
In Section 7 "Server to server interactions", the list of activities that require an object property should include the Announce activity.
In Section 6.1 "Client addressing", the list of activities that require an object property should include the Announce activity.
Section 7.1 "Delivery" should read in part This Activity is added by the receiver to the inbox OrderedCollection.
In section 7 "Server to Server Interactions", the link to Section 7.1.2 "Forwarding from Inbox" should be labeled "inbox forwarding".
In section 6 "Client to Server Interactions", a section should be inserted after section 6.5 "Follow activity" with the title "Accept activity" and the text: Upon receipt of an Accept activity into the outbox, if the object is an activity of type Follow, and the object of the Follow activity is not already in the actor's followers collection, and the Follow activity has not been undone by an Undo activity, then the server should add the actor of the Follow activity to the followers collection of the actor of the Accept activity.
In section 6 "Client to Server Interactions", a section should be inserted after section 6.5 "Follow activity" with the title "Reject activity" and the text: Upon receipt of a Reject activity into the outbox, if the object of the activity exists, and the object is an activity of type Follow, and the object of the Follow activity is not already in the actor's followers collection, and the Follow activity has not been undone by an Undo activity, then the Follow activity is rejected, and the actor of the Follow activity is not added to the followers collection.
In section 6.1 "Client Addressing", the third paragraph should begin: "Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo, context, and/or tag fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the addressing properties of the new Activity being created."
Section 5.1 "Outbox", second paragraph should read: The outbox stream contains activities the actor has published, subject to the ability of the requester to retrieve the activity (that is, the contents of the outbox are filtered by the permissions of the person reading it). If a requester submits a request without Authorization, the server should respond with all of the Public activities. This could potentially be all relevant activities published by the actor, though the number of available items is left to the discretion of those implementing and deploying the server.
In section B, a new subsection should be added with the title, "Uploaded JSON Objects", and the text "Some implementations will allow uploading media objects, either through Media Upload or other APIs. If these APIs allow uploading JSON files, without filtering them for AS2 content, they could be used to spoof activities or ActivityPub objects on the server.{paragraph} Compounding this problem is the common practice of comparing the origin of ActivityPub id URIs to validate relationships between objects, such as attribution. An unfiltered JSON object uploaded to the same server as other valid ActivityPub objects may be used to spoof attribution or make other harmful attacks.{paragraph} To mitigate this risk, implementing servers should not allow JSON or JSON-LD uploads. If JSON-LD files can be uploaded, they should be served with an opaque content-type such as application/binary or text/plain. They should also use a different domain for uploaded objects, so that consuming implementations can distinguish uploaded files from JSON objects created as part of the ActivityPub API. Consuming servers should also check the Content-Type of received objects, to make sure they are an acceptable AS2 media type. Consuming servers should also use other mechanisms besides the same-origin heuristic to confirm the validity of AS2 properties, such as finding a reverse property in the referenced object. This can be difficult for properties such as attribution."
Section 7 should read, in part, "POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" and GET requests (see also 3.2 Retrieving objects) with an Accept header including application/ld+json; profile="https://www.w3.org/ns/activitystreams"."
Section 4.1 "Actor objects" defines each of the "followers", "following", "liked" properties as "A link to an [ActivityStreams] collection of [...]". The use of the imprecise term "link" gives the erroneous impression that the representation of these values in a JSON-LD document must have a certain form, like an IRI. To avoid this implication, one possible correction is to change each of these definitions to "An [ActivityStreams] collection of [...]".
Example 9 shows an ActivityPub actor with an icon property that is an array with a single member. This is an error, since Activity Streams 2.0 objects should be compacted according to the JSON-LD API Compaction Algorithm, which would render an array with a single member as the value of the member. One possible correction is to replace the array value with the single member value, like "icon": "https://kenzoishii.example.com/image/165987aklre4"
Section 6, "Client to Server Interactions", does not include a section on the Announce activity, although Section 7, "Server to Server Interactions", does. This leaves out side-effects of posting an Announce activity, including updating the shares property for objects hosted locally. One possible correction is to add the following paragraph in a sub-section of section 6 entitled "Announce Activity": The Announce activity is used to share activities and other ActivityPub objects with the addressees. The side effect of receiving this in an outbox is that the server SHOULD add the activity to the shares collection of the object if the shares collection is maintained by the server. If the shares collection is maintained by a remote server, the receiving server SHOULD update or clear its cache for the affected objects, including the shares collection and shared object.
Section 6.8, "Like Activity", does not describe how or when to update the likes collection, which is an important side effect of the Like activity. One possible correction is to add the following paragraph to section 6.8: As another side effect, the receiving server SHOULD add the activity to the likes collection of the object if the likes collection is maintained by the receiving server. If the likes collection is maintained by a remote server, the receiving server SHOULD update or clear its cache for the affected objects, including the likes collection and the liked object.