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" should begin, 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 is incorrect, and should be removed.
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" should read, "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."
