7888: Remove the bit about redistributing received interactions and replace it with client addressing

fep/7888/fep-7888.md

@@ -73,30 +73,27 @@ For authoritative contexts that include such a canonical Collection, you SHOULD
 
 ## Interacting with `context`
 
-### Sending an interaction with or without `context`
+### Choosing whether to participate in the same context
 
 When encountering an object with a `context` and choosing to author your own object or activity that interacts with this object:
 
 - You MAY copy a `context` as-is, if you wish for your object to be included in that same context.
-  - If you do this, you SHOULD send your activity to the owner(s) of the context(s), defined via `context.attributedTo` if resolvable. This is similar to how one might address the author of an object that they are responding to via `inReplyTo.attributedTo`, as a social courtesy.
 - You MAY set your own `context`, if you wish for your object to exist in a different context.
 - You MAY remove the `context` entirely, if you wish for your object to exist on its own.
 
 Note that `context` can be present on either the object, the activity, or both. It is also possible for different `context` references to be placed on each. This depends on how `context` is used. In the case of an activity wrapping an object with context, if the activity is deemed to exist in the same context as the object, then you SHOULD use the same `context` reference on both the object and also on its wrapping activity.
 
-### Receiving an interaction with your `context`
+### Keeping relevant entities in the loop
 
-Upon receipt of an activity where a `context` is owned by you, or where the activity's `object` has a `context` owned by you:
+Per [PUB] Section 6.1 "Client Addressing":
 
-You SHOULD distribute the object or activity that declares your `context` to the audience of that context. The audience of the context MAY be possibly specified by `context.audience`, and MAY possibly include `context.followers` if the context is itself an actor.
+> Clients SHOULD look at any objects attached to the new Activity via the `object`, `target`, `inReplyTo` and/or `tag` fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the `to` or `cc` fields of the new Activity being created. Clients MAY recurse through attached objects, but if doing so, SHOULD set a limit for this recursion. (Note that this does not suggest that the client should "unpack" collections of actors being addressed as individual recipients).
+>
+> Clients MAY give the user the chance to amend this addressing in the UI.
 
-Distribution to the audience of the context MAY be done by the following mechanisms:
+This FEP extends the recommendation to look at `object`, `target`, `inReplyTo`, and/or `tag` to also include `context`.
 
-- Inbox forwarding. If the object or activity to be distributed addresses `context.audience` and/or `context.followers` as collections, then inbox forwarding MAY suffice to notify interested actors about the new activity or object. (Verification mechanisms for inbox forwarding are out-of-scope for this FEP.)
-- Add activity. To properly manage the canonical collection's state (when the context has a canonical collection associated with it), the context owner SHOULD locally Add the appropriate object or activity to the canonical collection. This Add activity MAY also be delivered over ActivityPub S2S while addressing the `context.audience` and/or `context.followers` as recipients, serving as a notification that the object or activity was included in the canonical collection by the context owner.
-- Other mechanisms. It is possible that the software managing a context's canonical collection may use other protocols or activity-forms to distribute relevant objects or activities. Non-normative examples include Announce or potential extension activity types.
-
-You MAY drop certain activities not matching specific policies; for example, you might filter out spam, or implement a policy such that only certain actors (members, participants, etc.) are allowed to be included in the context. (Signaling which actors can participate is out-of-scope for this FEP and may be covered in a further FEP.)
+If copying someone else's context, you SHOULD send your activity to the owner(s) of the context(s), defined via `context.attributedTo` if resolvable. This is similar to how one might address the author of an object that they are responding to via `inReplyTo.attributedTo`, as a social courtesy. You MAY also want to address `context.followers` and/or addressing properties like `context.audience`.
 
 ---