Who’s allowed to reply to your posts?

Truthfully, anyone who can see it (and nothing can prevent someone who wants to from seeing something you make public). If they have to, they can link, copy and paste or screenshot it, and fundamentally there’s no way of stopping them.

But that’s not really what we’re talking about when we talk about replies on social network’s. What we’re really talking about is who’s replies get to show up under your post; or, in other words, who gets to borrow your audience.

The centralised networks have chosen to give the post’s author control of this; and for good reason: it’s not good to let harassers, stalkers and spammers borrow your audience.

In general, the centralised networks will prevent blocked users from replying, and will (often) also reduce visibility of posts by users who were blocked after said post was created. Occasionally they will even grant the post author the ability to “hide” specific replies (generally behind a “Show hidden replies” button or similar)

Defining Replies

In ActivityPub, like the pump.io protocol and OStatus before them, replies are identified by having an inReplyTo field containing the ID of the parent post.

If you send a post inReplyTo one of mine to my instance and I block you, then your reply won’t show up on my instance. However, if you send it to a third instance, that instance won’t be aware of the block that exists between us (and it shouldn’t be: federating blocks even to the blocked user’s instance is already a harassment vector!)

This means that, today, blocks only work to stop people borrowing your audience if the blocked user is on a server which honours your blocks (or is universally defederated). This, of course, means it’s not reliable; it is relatively trivial to patch out incoming block handling from any piece of software (or just delete the block from the database).

(It’s also possible for the occasional block to just go missing - as with any message; and if you’re on a Pleroma or Akkoma instance, then your blocks probably aren’t federated outwards: they disable this by defult, because as mentioned before it is a harassment vector)

Worse, it grants a false sense of security: their posts will disappear for you, but not for people on other instances you federate with.

An argument could be made that this could be fixed with better moderation, but there are always going to be edge cases, disagreements, and new hives of scum and villainy that aren’t blocked yet.

It’s hard for me to tell, but it appears that BlueSky is making the same mistake (it is possible that their approach will involve more widely federating blocks, but it’s hard to tell; and federating blocks more widely comes with its' own harassment concerns)

Solutions

There is no 100% solution to this problem; even if the protocol did not include replies, people would find a way to make them. The corner of the network that hates you always has the option of reinventing Google Sidewiki or similar systems in which replies exist outside of the network itself.

But that’s, on the whole, fine: what we care about is the replies that our friends on “good” servers see. And the fix is fundamentally simple: We change the rule for which replies are displayed from “anything inReplyTo this post” to “anything inReplyTo this post which was approved by the author of the parent post” (and then we introduce an ApproveReply activity to federate those approvals).

Approval can then be done automatically by your instance, simply by following your block/mute list or according to whichever rules you choose.

Some might raise issues of censorship here, and they’re not completely invalid. Giving absolute control over replies to someone comes with risks; but I think there are two important ways to mitigate this:

1. The approval only shows what replies show up under a post; it doesn’t prevent the backlink from appearing when viewing a reply.
2. Unapproved replies need not be removed completely; the can simply be hidden behind a “Show hidden replies” button (similar to the one which Twitter has, and which often hides a bunch of cryptocurrency scams). This is, fundamentally, an implementation decision.

For migration purposes, we can add a repliesRequireApproval (or similar) flag to posts to indicate that they are opting in to the new mode; over time, more and more instances will upgrade, and more and more posts will be in approved reply mode.