Unruffled [they/them]

Ok, I won’t try to drag you into it. But if you feel you can support this alternative proposal or some (enhanced) variation of it, then I think we can work to find common ground, if the devs are open to it.

Hi Snoopy, please see my recent comment for another suggestion on how to manage the issue of modlog removals: https://anarchist.nexus/post/643502/comment/3833833

Edit: I realized it was missing an arrow.

I 100% agree modlog abuse is something that needs to be addressed. But I’d much prefer for admins and users to be consulted about such changes, because Rimu’s currently “solution” undermines trust, breaks transparency, and breaks normal federation. That’s why one gung ho developer doing whatever he pleases can be a liability on occasion instead of an asset.

I’d like to suggest an alternative approach that could work for both Lemmy and Piefed, while maintaining normal federation.

Proposed process for “Restricting” visibility of a modlog entry:

Type 1

• Person: The originating instance admin/moderator
• Action: During admin or mod comment/post removal, enable a toggle to set the modlog entry as “Restricted”

Type 2

• Person: The originating instance admin only
• Action: If admin user, enable on/off toggle for “Restricted” flag for a modlog entry which will override any previously set flag. The updated flag status would then federate out to all federated instances.

Type 3

• Person: federated instance admins only
• Action: If admin user, enable on/off toggle for “Restricted” flag for a modlog entry which will override any previously set flag. The updated flag status would only apply to the federated instance and would not federate out.

Explanation

For type 1 scenarios, once a mod or admin at the originating instance performs a comment or post removal, they would have the option to restrict public access to the modlog entry. There should be a clear warning, “This option should be used very sparingly, and only for defamatory comments, CSAM, or personally identified information.” The default should be for “restricted” status to be off, as is the case currently. This alone would deal with a great many of these issues.

For type 2 scenarios, instance admins would be able to override the status of the “restricted” toggle for all modlog entries. That will enable admins to override the status set by mods within their own instance. If set by an admin of the originating instance, then then updated “restricted” status should federate to all federated instances. This will allow us to deal with the occasions where internal mod actions need to be overruled.

For type 3 scenarios, this allows for any instance to have the freedom to override the federated status of the modlog entry at the admin’s discretion. That allows for whistleblowing in event an instance is abusing the “Restricted” flag, and maintains the independence of each instance to make that choice for themselves. Of course, doing so may invite a defederation or other sanctions if other admins disagreed with changing the “restricted” status. So I think this is a reasonable checks-and-balances approach, which provides necessary info to federated instance admins, so we can all trust that the function is not being abused.

What I would really like is some serious engagement from the developers of PieFed and Lemmy on this issue, since it is clearly something that we would all like to see resolved as a priority item. Currently I believe the software platform itself is likely non-compliant with GDPR requests due to the current modlog implementation.

Rimu’s “solution” really fixes nothing because there is a simple and obvious workaround. A user creates an account on piefed.social or another “trusted” instance, creates a community on that instance, then weaponizes the modlog from within the trusted circle.

And in addition to not addressing the fundamental issue, the “solution” also introduces the concept of two-tiers of federation. The “trusted” instances get “first-class” federation, but anyone the admin feels are not trusted gets assigned a “second-class” version of federation, including much less visibility. That is simply shadow banning under another name, and it feels like a way too Reddit-like for comfort, imo. The user should be in full control of their own feed preferences, not the instance admin.

I also think that by default, all moderation actions and content should continue to be public as a core principle. A removal from the modlog should be the exception, not an instance-wide rule that is set at the whim of one person.

Does this not seem like a more reasonable and sane approach to take? Rimu’s approach appears to have been unilaterally decided, poorly thought out, and quite honestly just makes me want to step away from the PieFed project altogether. Why was community feedback not sought before this change was implemented? And why was Rimu’s particular implementation decided to be the best path forward for PieFed? I’d like to understand whether other developers and admins actually using PieFed are actually being consulted about these changes in advance, or are these ultimately unilateral decisions being made by one person with a short fuse?

Hi again,

Ok, so good news.

The user has agreed to delete the comment in the morning (it would be 3am for them now as they messaged me about an hour ago) so that should also give Mr Kaplan time to restore it.

So if you check in about 8-10 hours, hopefully it will be deleted.

It will need to be restored only so that the user can delete it themselves. I have asked them as their instance admin, so I anticipate they will comply. We will need to give them a reasonable amount of time to respond though.

I think this is the only viable way to get this done easily, given the way federation works, so I think we should give it a shot.

Just a quick update. This is more complicated than it might seem at first glance. I spoke to a couple of other admins including Mr Kaplan from LW and apparently the only mechanism in Lemmy to federate out a removal of a modlog entry is for them to restore the comment, and then have the OP on anarchist.nexus delete the comment themselves.

I have reached out to the person who posted that comment and asked them if they are willing to delete it. If not, then I think the only alternative would be to reach out to every single federated instance admin to purge the comment manually. And I don’t like your chances of reaching them all. This particular scenario has not been catered for yet in the software, unfortunately.

So, I am just waiting to hear back from the user. If they agree to delete the comment, then I will contact Kr Kaplan again to have the comment restored, and it should then be deleted shortly after that by the OP.