diff --git a/draft/index.html b/draft/index.html index 7290a41..da21cfc 100644 --- a/draft/index.html +++ b/draft/index.html @@ -1518,7 +1518,7 @@ codeberg Informational -- +#891 Discussions 2026-07-19 diff --git a/fep/8c13/index.html b/fep/8c13/index.html index aeaa850..dbb32d1 100644 --- a/fep/8c13/index.html +++ b/fep/8c13/index.html @@ -1081,6 +1081,17 @@ + + +
  • + + + + Deletion Fallback on Policy Tightening (Normative, Optional) + + + +
  • @@ -1842,19 +1853,32 @@ determined by comparing its Effective Addressing against the root object's curre reactions, edits, deletes, etc.).

    Inherited ("follow-post") addressing: Effective Addressing exactly equal (set-equality, order-insensitive) to the -root object's current to/cc. This signals "same visibility as thread."

    +root object's current to/cc. This signals "same visibility as thread." Inherited activities are forwarded with the +Thread Policy addressing.

    Narrowed addressing: An activity MAY narrow visibility using any addressing forms permitted by ActivityPub -(individual actor IRIs and/or collections), provided the resulting Effective Addressing is not more permissive than the -current Thread Policy and is a subset of the Authorized Recipient Set under the current Thread Policy and local policy.

    -

    The Context Authority MUST evaluate whether the narrowed Effective Addressing is a subset of the Authorized -Recipient Set, including membership in collections it controls (e.g. followers). If it cannot determine subset safety -(e.g. unknown external collection semantics), it MUST treat the activity as more permissive and MUST reject it -for context routing.

    -

    For narrowed activities, the Context Authority MUST preserve the sender's narrowed Effective Addressing when -forwarding, except to remove recipients no longer authorized under the current Thread Policy and local policy. It -MUST NOT widen a narrowed activity to the full Thread Policy.

    -

    Prohibited addressing: An activity MUST NOT be more permissive than the Thread Policy. Violations MUST be -rejected by the Context Authority.

    +(individual actor IRIs and/or collections), provided every entry of its Effective Addressing is authorized under the +current Thread Policy and local policy.

    +

    Address Filtering: The Context Authority MUST compute the filtered addressing of every Context Activity: +the Effective Addressing with every entry removed that the Context Authority cannot verify as authorized under the +current Thread Policy and local policy. Verification uses locally available state for collections the Context Authority +controls (e.g. followers) and string-level comparison against the Thread Policy for all other entries; entries whose +authorization cannot be established (e.g. collections with unknown semantics, or the public sentinel when the Thread +Policy does not include it) MUST be removed.

    + +

    The forwarded addressing MUST NOT contain any entry absent from the sender's Effective Addressing (no widening) and +MUST NOT be more permissive than the current Thread Policy. A Context Authority MAY additionally reject an +activity by local policy (for example, one whose Effective Addressing includes the public sentinel in a direct thread). +Filtering, not rejection, is the interoperable default for over-broad addressing: rejection does not prevent the +sender's own server from delivering the activity to the addressed audience, it only removes the activity from the +thread.

    Recipient set equality: Two addressing fields are equal if they contain the same IRIs as a set, ignoring order and duplicates. Implementations MUST canonicalize lists before comparison by removing duplicates and sorting lexicographically by Unicode code points. Comparison is string-based only: implementations MUST NOT dereference @@ -1912,11 +1936,13 @@ delivery coincide, and the Context Authority forwards to the Authorized Recipien controls. The two subsections below add the rules for the direct and public classes.

    Direct Conversations (Normative)

    When the Thread Policy is a set of explicit actor IRIs (a direct message or an enumerated private group), the -Authorized Recipient Set and the Delivery Target are both that explicit actor set, so subset checks under the -Reply Visibility Rules are exact: a reply addressing any actor outside the set - or -as:Public - is more permissive than the Thread Policy and MUST be rejected, which is what stops a participant from -leaking the thread by replying broadly. Membership is changed by the root author updating the root object's to/cc, -propagated via Root Policy Update Propagation.

    +Authorized Recipient Set and the Delivery Target are both that explicit actor set, so Address Filtering under the +Reply Visibility Rules is exact: any actor outside the set - and as:Public - is removed +from the forwarded addressing, and a reply retaining no member of the set is rejected. The Context Authority thus never +amplifies an over-broad reply beyond the member set; whether the sender's own server delivers that reply elsewhere is +outside the Context Authority's control, as in ordinary ActivityPub federation. Membership is changed by the root +author updating the root object's to/cc, propagated via +Root Policy Update Propagation.

    The Author Proof is the primary defense against the Context Authority fabricating a message attributed to another participant; recipients MUST reject forwarded activities whose Author Proof does not verify against the activity actor. Routing through one instance still lets it withhold or reorder messages (forgery is prevented, censorship is @@ -2023,9 +2049,9 @@ current Thread Policy (root to/cc) plus local rules (b Alignment).

  • Authenticate the sender via transport (HTTP Signatures or equivalent) and map the request to an ActivityPub actor.
  • Check sender authorization to submit Context Activities, informed by the current Thread Policy and local policy.
    • -
  • Verify the activity's addressing conforms to the Reply Visibility Rules. Subset - evaluation MUST use locally available state for collections it controls (including followers) and any local - policy inputs.
    • +
  • Apply Address Filtering to the activity's addressing per the Reply Visibility Rules, + rejecting the activity if the filtered addressing is empty. Authorization evaluation MUST use locally available + state for collections it controls (including followers) and any local policy inputs.
  • Verify the Author Proof: canonicalize with the Author Proof exclusions, then verify against the referenced verification method (which MUST belong to the activity's actor). An Author Proof is verified iff present and successfully verified.
    • @@ -2118,12 +2144,10 @@ follower collection to its remote inboxes does not require rewriting the activit

    The Context Authority MUST NOT rewrite to/cc to enumerate individual actor IRIs solely to target specific recipients.

    The Context Authority MAY rewrite to/cc to make forwarded deliveries conform to the current Thread Policy, -including when:

    - -

    If the sender's addressing is more permissive than the current Thread Policy, the activity MUST be rejected.

    +including when the Thread Policy changed since the sender last observed the root object.

    +

    If the sender's Effective Addressing contains entries not authorized under the current Thread Policy, the Context +Authority MUST forward the activity with its filtered addressing, or reject it if the filtered addressing is empty, +per Address Filtering in the Reply Visibility Rules.

    When forwarding an embedded-object activity, rewiring MUST be applied consistently: