mirror of
https://codeberg.org/fediverse/fep.git
synced 2026-08-05 19:55:46 +00:00
Update FEP-5624 (#97)
Update FEP-5624 with the following changes: - clarify that the authority can forward replies and that when doing so, those replies should be considered approved - use special-purpose activities instead of ambiguous `Accept` and `Reject` Co-authored-by: Claire <claire.fep-1d7d@sitedethib.com> Reviewed-on: https://codeberg.org/fediverse/fep/pulls/97 Co-authored-by: ClearlyClaire <clearlyclaire@noreply.codeberg.org> Co-committed-by: ClearlyClaire <clearlyclaire@noreply.codeberg.org>
This commit is contained in:
ClearlyClaire
committed by
David Sterry
David Sterry
parent
652e6d1d6a
commit
565a08889b
+37
-20
@@ -62,44 +62,60 @@ After locally verifying that the replier should be allowed to reply, the replier
|
||||
|
||||
When receiving a reply to an object with a `canReply` property, the authority decides whether the reply is acceptable.
|
||||
|
||||
If the reply is considered acceptable, the authority MUST reply with an `Accept` activity with the `object` property set to the `id` of the reply object, and its `inReplyTo` property set to the object it is in reply to.
|
||||
If the reply is considered acceptable, the authority MUST reply with an `ApproveReply` (`http://joinmastodon.org/ns#ApproveReply`) activity with the `object` property set to the `id` of the reply object, and its `inReplyTo` property set to the object it is in reply to.
|
||||
|
||||
That `Accept` activity SHOULD be publicly dereferenceable and MUST be dereferenceable by all parties allowed to see the original post. It MUST NOT embed its `object` nor its `inReplyTo` as to avoid possible information leaks.
|
||||
That `ApproveReply` activity SHOULD be publicly dereferenceable and MUST be dereferenceable by all parties allowed to see the original post. It MUST NOT embed its `object` nor its `inReplyTo` as to avoid possible information leaks.
|
||||
|
||||
If the reply is considered unacceptable, the authority SHOULD reply with a `Reject` activity. This activity MAY be publicly accessible, but this is not a requirement.
|
||||
Additionally, the authority MAY forward an accepted reply according to its own rules.
|
||||
|
||||
### Example `Accept` activity
|
||||
If the reply is considered unacceptable, the authority SHOULD reply with a `RejectReply` (`http://joinmastodon.org/ns#RejectReply`) activity. This activity MAY be publicly accessible, but this is not a requirement.
|
||||
|
||||
The reason for using the new activity types `ApproveReply` and `RejectReply` is to be explicit about the purpose of the approval, as one could imagine other kinds of approvals, and remaining implicit may cause ambiguities with other potential extensions.
|
||||
|
||||
### Example `ApproveReply` activity
|
||||
|
||||
```
|
||||
{
|
||||
"@context": "https://www.w3.org/ns/activitystreams",
|
||||
"@context": [
|
||||
"https://www.w3.org/ns/activitystreams",
|
||||
{
|
||||
"toot": "http://joinmastodon.org/ns#",
|
||||
"ApproveReply": "toot:ApproveReply"
|
||||
}
|
||||
],
|
||||
"actor": "https://example.com/users/1",
|
||||
"id": "https://example.com/reply_approvals/1",
|
||||
"type": "Accept",
|
||||
"type": "ApproveReply",
|
||||
"object": "https://example.org/users/bob/statuses/3",
|
||||
"inReplyTo": "https://example.com/users/1/statuses/1"
|
||||
}
|
||||
```
|
||||
|
||||
### Example `Reject` activity
|
||||
### Example `RejectReply` activity
|
||||
|
||||
```
|
||||
{
|
||||
"@context": "https://www.w3.org/ns/activitystreams",
|
||||
"@context": [
|
||||
"https://www.w3.org/ns/activitystreams",
|
||||
{
|
||||
"toot": "http://joinmastodon.org/ns#",
|
||||
"RejectReply": "toot:RejectReply"
|
||||
}
|
||||
],
|
||||
"actor": "https://example.com/users/1",
|
||||
"id": "https://example.com/reply_approvals/1",
|
||||
"type": "Reject",
|
||||
"type": "RejectReply",
|
||||
"object": "https://example.org/users/bob/statuses/3"
|
||||
}
|
||||
```
|
||||
|
||||
## Receiving approval and distributing the reply
|
||||
|
||||
After sending the initial `Create`, the replier SHOULD wait for an `Accept` activity such as described above.
|
||||
After sending the initial `Create`, the replier SHOULD wait for an `ApproveReply` activity such as described above.
|
||||
|
||||
Once the `Accept` has been received, the replier SHOULD add a `replyApproval` (`http://joinmastodon.org/ns#replyApproval`) property to their reply object pointing to the `Accept` activity they received, and then MAY send a `Create` activity with the modified object to its intended audience.
|
||||
Once the `ApproveReply` has been received, the replier SHOULD add a `replyApproval` (`http://joinmastodon.org/ns#replyApproval`) property to their reply object pointing to the `ApproveReply` activity they received, and then MAY send a `Create` activity with the modified object to its intended audience.
|
||||
|
||||
If it instead receives a `Reject`, the reply SHOULD be immediately deleted and the replier MAY be notified.
|
||||
If it instead receives a `RejectReply`, the reply SHOULD be immediately deleted and the replier MAY be notified.
|
||||
|
||||
### Example reply object with `replyApproval`
|
||||
|
||||
@@ -131,11 +147,12 @@ If it instead receives a `Reject`, the reply SHOULD be immediately deleted and t
|
||||
|
||||
When processing a reply from a remote actor to a remote authority, a recipient SHOULD discard any reply that does not match any of the following conditions:
|
||||
- the object it is in reply to does not set a `canReply` property
|
||||
- the object has been received through the remote authority
|
||||
- the object it is in reply to has a `canReply` containing the `as:Public` collection
|
||||
- the author of the reply appears in a `Mention` object in the `tag` property of the object it is in reply to
|
||||
- the object it is in reply to sets a non-empty `canReply`, and `replyApproval` can be dereferenced and is a valid `Accept` activity
|
||||
- the object it is in reply to sets a non-empty `canReply`, and `replyApproval` can be dereferenced and is a valid `ApproveReply` activity
|
||||
|
||||
To be considered valid, the `Accept` activity referenced in `replyApproval` MUST satisfy the following properties:
|
||||
To be considered valid, the `ApproveReply` activity referenced in `replyApproval` MUST satisfy the following properties:
|
||||
- its `actor` property is the authority
|
||||
- its authenticity can be asserted
|
||||
- its `object` property is the reply under consideration
|
||||
@@ -147,15 +164,15 @@ In addition, if the reply is considered valid, but has no valid `replyApproval`
|
||||
|
||||
The authority may want to perform /a posteriori/ moderation of their replies.
|
||||
|
||||
To do this, the authority SHOULD send a `Reject` activity to the sender and the reply's audience, with the reply URI as the `object` property. The `object` property MUST NOT be embedded, as to avoid possible information leaks.
|
||||
To do this, the authority SHOULD send a `RejectReply` activity to the sender and the reply's audience, with the reply URI as the `object` property. The `object` property MUST NOT be embedded, as to avoid possible information leaks.
|
||||
|
||||
The URI at which the previously-offered `Accept` was available should return HTTP 404 or redirect to the newly-issued `Reject` activity.
|
||||
The URI at which the previously-offered `ApproveReply` was available should return HTTP 404 or redirect to the newly-issued `RejectReply` activity.
|
||||
|
||||
## Handling a revocation
|
||||
|
||||
Upon receiving a `Reject` activity for a previously-accepted reply, third-parties SHOULD check that the `Reject` is valid and SHOULD delete or hide the revoked reply if it is.
|
||||
Upon receiving a `RejectReply` activity for a previously-accepted reply, third-parties SHOULD check that the `RejectReply` is valid and SHOULD delete or hide the revoked reply if it is.
|
||||
|
||||
To be considered valid, the `Reject` activity MUST satisfy the following properties:
|
||||
To be considered valid, the `RejectReply` activity MUST satisfy the following properties:
|
||||
- its `actor` property is the authority
|
||||
- its authenticity can be asserted
|
||||
- its `object` property is the reply under consideration
|
||||
@@ -166,11 +183,11 @@ Because it is unrealistic to expect all implementations and deployments to imple
|
||||
|
||||
## Security considerations
|
||||
|
||||
By not adding a hash or copy of the reply in the `Accept` activity, malicious actors could exploit this in a split horizon setting, sending different versions of the same activity to different actors. This is, however, already a concern in pretty much all contexts in ActivityPub, and enshrining that information in the `Accept` activity would have many drawbacks:
|
||||
By not adding a hash or copy of the reply in the `ApproveReply` activity, malicious actors could exploit this in a split horizon setting, sending different versions of the same activity to different actors. This is, however, already a concern in pretty much all contexts in ActivityPub, and enshrining that information in the `ApproveReply` activity would have many drawbacks:
|
||||
|
||||
- significantly more complex implementation
|
||||
- inability to change the JSON-LD representation after the fact
|
||||
- possibly leaking private information if the `Accept` activity is publicly dereferenceable
|
||||
- possibly leaking private information if the `ApproveReply` activity is publicly dereferenceable
|
||||
|
||||
|
||||
## Implementations
|
||||
|
||||
Reference in New Issue
Block a user