Slop.

Wait. The logic flow makes sense though. I've been double checking this. The proactively_delete_reply only proactively deleted if the parent user has the replying user blocked.

What this means, is that this function is attempting to mirror the host instance even closer. LocalUser (LU) blocks RemoteUser(RU). LU makes a comment that federates to RU's instance. RU replies and their comment is sent back to LU instance.

LUs community where the comment is received checks its inbox. It then validates the comment. It then checks to see if the comment is from a site banned user, it passes. It then checks if the RU is blocked by the parent comment user (LU), it fails.

In 1.5.X currently this returns None thus never storing the comment.

In the main branch however, a secondary task is fired off, calling proactively_delete_reply only if the community is local. proactively_delete_reply searches for a mod or admin account and sends a moderator action back to the remote server with the note "Automatic delete do to block".

This is because of a few reasons:

1. They prevent local users from leaving comments on posts and comments from users who block them using the UI.
2. They CANNOT do this for remote piefed instances (I think). They obviously can't do it for Lemmy instance. Thus the Return None.
3. Now this new code enforces the removal of the comment on the remote server because it is already stored in the DB.

They are effectively enforcing blocks at the DB level instead of the API level. Lemmy to my understanding will simply flag the user as blocked and it is on developers to prevent the content from being displayed to the user.

The implications seem to be that in the future if a Lemmy user replies to a post or comment from a piefed local community, and the author blocks them, a federated mod action will be sent to the Lemmy server to remove the comment.