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.
Section 5.3 "Followers Collection" erroneously says that the "followers" collection is a list of everyone who has sent a Follow activity for the actor (emphasis added). Because the receiving actor can optionally Reject a Follow activity, the sending actor can later Undo a Follow activity, and one or both could Block the other, not everyone who sends a Follow activity will be in the list of followers. A possible correction is to replace the text with Every actor SHOULD have a followers collection. This is where one would find a list of all the actors that are following the actor.
In section 7.5 "Follow Activity", the second paragraph erroneously describes processing requirements for receiving an Accept activity with a Follow activity as the object. It describes changing the "followers" collection; however, receiving an "Accept" activity over the federation protocol would result in a change to the "following" collection. The correct behaviour is already described in section 7.6 "Accept Activity". One possible correction is to simply remove the second paragraph of section 7.5.
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 4.1 "Actor objects", the definition of "inbox" uses the imprecise term "reference" and is different from the definition of "outbox", giving the false impression that the range of the "inbox" property is different than that of "outbox". A possible correction is to make the definition of inbox parallel with that of outbox: "An OrderedCollection comprised of all the messages received by the actor; see 5.2 Inbox."
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 [...]".
