A thread owner's Add of a reply to its context is the reply passed on

FEP-171b, received (Hubzilla, Streams, Forte): an Add whose target is a collection of the actor's own server, and whose
object is someone's Create, Update or Delete of their own object, is queued as that activity forwarded by the owner, so
it is believed on its FEP-8b32 proof or as its origin has it, and shares its job with the plain forward Hubzilla also
sends. Checked live against Hubzilla (unchanged, 20 checks).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw

docs/INTEROP.md

@@ -865,8 +865,8 @@ without a port, before it gives out its OAuth client.
   permission") while answering 200.
 - **Threads are its owner's:** a comment by another channel in a thread goes to the owner, who passes it on to the
   thread's audience as the commenter's own Create, with the commenter's FEP-8b32 proof, and adds each activity to the
-  thread's `context` (FEP-171b, `Add{Create}`). PrivaPub takes the forwarded Create on its proof; the `Add` is dropped,
-  the Create having said it already.
+  thread's `context` (FEP-171b, `Add{Create}`). PrivaPub takes the forwarded Create on its proof, and unwraps the `Add`
+  as the same activity passed on (one job for both, whichever comes first); an added `Like` is not taken.
 - **Signs everything with a proof** (FEP-8b32) and verifies HTTP signatures; NodeInfo comes from its `statistics`
   addon.
 - **An unfollow changes nothing there** (G-0010): `Activity::unfollow` deletes the setting `system.their_perms`, which