FEP-5624: Per-object reply control policies #17

Merged
weex merged 1 commits from ClearlyClaire/fep:main into main 3 weeks ago

Sometimes, users may want to share an information or a story without inviting replies from outside their circles or from anyone at all. In particular, individuals may want to restrict who can reply to them in order to avoid “reply guys” or limit outright harassment, while instutions may want to disable replies on their posts to provide information without having to deal with a moderation burden.

This FEP intends to provide a mechanism to address that, by advertising a reply policy and providing means to check whether an actor has approved a reply.

Sometimes, users may want to share an information or a story without inviting replies from outside their circles or from anyone at all. In particular, individuals may want to restrict who can reply to them in order to avoid “reply guys” or limit outright harassment, while instutions may want to disable replies on their posts to provide information without having to deal with a moderation burden. This FEP intends to provide a mechanism to address that, by advertising a reply policy and providing means to check whether an actor has approved a reply.
ClearlyClaire added 1 commit 3 months ago
silverpill reviewed 3 months ago
The software SHOULD NOT offer the user to reply unless it is directly mentioned in the object's `tag` attribute or listed in `canReply` (either directly or through a collection), or `canReply` contains a collection for which the recipient cannot efficiently check the membership of the would-be replier.
After locally verifying that the replier should be allowed to reply, the replier's end SHOULD `POST` the `Create` activity for the reply to the authority's inbox *only*, and consider the reply to be pending approval.

What is the argument for placing the burden of interacting with the authority on the replier?
The receiving side can also do that, but in such case the server-to-server interaction will be simpler: (Create, Accept) vs (Create, Accept, Create with approval), and authority will be able to work without ActivityPub inbox (easier to implement).

What is the argument for placing the burden of interacting with the authority on the replier? The receiving side can also do that, but in such case the server-to-server interaction will be simpler: `(Create, Accept)` vs `(Create, Accept, Create with approval)`, and authority will be able to work without ActivityPub inbox (easier to implement).

This keeps audience under the control of the replier, as is currently the case in most scenarios/implementations. It's also important the replyApproval property is set on the replier's side when third-party servers start fetching the object.

This keeps audience under the control of the replier, as is currently the case in most scenarios/implementations. It's also important the `replyApproval` property is set on the replier's side when third-party servers start fetching the object.
- 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

If authority role has been introduced with the intention to allow delegation of moderation tasks to 3rd parties, I think the implications of this should be considered too.
For example, a malicious authority can interfere with communication between actors who are in fact willing to communicate. This could be especially dangerous if there is only a small number of such authorities (due to economies of scale or some other reason).

If authority role has been introduced with the intention to allow delegation of moderation tasks to 3rd parties, I think the implications of this should be considered too. For example, a malicious authority can interfere with communication between actors who are in fact willing to communicate. This could be especially dangerous if there is only a small number of such authorities (due to economies of scale or some other reason).

The concept of authority is mentioned to let the following two cases possible:

  • groups, in this case the authority would be the group actor
  • replies when replies are considered to be second-class and existing only in the context of the root post (“posts and comments”, in the style of facebook), in this case the authority would be the author of the original post
The concept of authority is mentioned to let the following two cases possible: - groups, in this case the authority would be the group actor - replies when replies are considered to be second-class and existing only in the context of the root post (“posts and comments”, in the style of facebook), in this case the authority would be the author of the original post
weex merged commit e39f27e732 into main 3 weeks ago
The pull request has been merged as e39f27e732.
Sign in to join this conversation.
Loading…
There is no content yet.