[feature] Distribute + ingest Accepts to followers (#3404)

docs/federation/posts.md

@@ -569,6 +569,7 @@ For example, the following json object `Reject`s the attempt of `@someone@somewh
 
 ```json
 {
+  "@context": "https://www.w3.org/ns/activitystreams",
   "actor": "https://example.org/users/post_author",
   "to": "https://somewhere.else.example.org/users/someone",
   "id": "https://example.org/users/post_author/activities/reject/01J0K2YXP9QCT5BE1JWQSAM3B6",
@@ -591,7 +592,12 @@ For example, the following json object `Accept`s the attempt of `@someone@somewh
 
 ```json
 {
+  "@context": "https://www.w3.org/ns/activitystreams",
   "actor": "https://example.org/users/post_author",
+  "cc": [
+    "https://www.w3.org/ns/activitystreams#Public",
+    "https://example.org/users/post_author/followers"
+  ],
   "to": "https://somewhere.else.example.org/users/someone",
   "id": "https://example.org/users/post_author/activities/reject/01J0K2YXP9QCT5BE1JWQSAM3B6",
   "object": "https://somewhere.else.example.org/users/someone/statuses/01J17XY2VXGMNNPH1XR7BG2524",
@@ -601,6 +607,9 @@ For example, the following json object `Accept`s the attempt of `@someone@somewh
 
 If this happens, `@[email protected]` (and their instance) should consider the interaction as having been approved / accepted. The instance can then feel free to distribute the interaction `Activity` to all of the recipients targed by `to`, `cc`, etc, with the additional property `approvedBy` ([see below](#approvedby)).
 
+!!! Note
+    In the above example, actor `https://example.org/users/post_author` addresses the `Accept` activity not just to the interacting actor `https://somewhere.else.example.org/users/someone`, but to their followers collection as well (and, implicitly, to the public). This allows followers of `https://example.org/users/post_author` on other servers to also mark the interaction as accepted, and to show the interaction alongside the interacted-with post.
+
 ### Validating presence in a Followers / Following collection
 
 If an `Actor` interacting with an `Object` (via `Like`, `inReplyTo`, or `Announce`) is permitted to do that interaction based on their presence in a `Followers` or `Following` collection in the `always` field of an interaction policy, then their server should *still* wait for an `Accept` to be received from the server of the target account, before distributing the interaction more widely with the `approvedBy` property set to the URI of the `Accept`.

internal/ap/activitystreams.go

@@ -77,6 +77,10 @@ const (
 	// See https://www.w3.org/TR/activitystreams-vocabulary/#microsyntaxes
 	// and https://www.w3.org/TR/activitystreams-vocabulary/#dfn-tag
 	TagHashtag = "Hashtag"
+
+	// Not in the AS spec, just used internally to indicate
+	// that we don't *yet* know what type of Object something is.
+	ObjectUnknown = "Unknown"
 )
 
 // isActivity returns whether AS type name is of an Activity (NOT IntransitiveActivity).

internal/federation/dereferencing/status.go

@@ -527,8 +527,9 @@ func (d *Dereferencer) enrichStatus(
 	// serve statuses with the `approved_by` field, but we
 	// might have marked a status as pre-approved on our side
 	// based on the author's inclusion in a followers/following
-	// collection. By carrying over previously-set values we
-	// can avoid marking such statuses as "pending" again.
+	// collection, or by providing pre-approval URI on the bare
+	// status passed to RefreshStatus. By carrying over previously
+	// set values we can avoid marking such statuses as "pending".
 	//
 	// If a remote has in the meantime retracted its approval,
 	// the next call to 'isPermittedStatus' will catch that.