Modlog visiblity changes?

Sounds alright to me. The modlog is there for transparency and accountability. And I think that would still work out if we offer that to members only. It’s not too hard to sign up somewhere on the Fediverse.

In the long-term, I always thought bans and defederation are way too blunt tools. Appreciate the new silencing feature. I think we also could talk about adding nuance to the bans. A formal appeals process would be nice. Last time I had issues with a mod, they had DMs turned off or blocked me, dunno. And all the other mods were inactive. So the design left me in a bad place, there’s 100% power to the mods and nobody factored in abuse or them making mistakes, and a possible step after the mod decision. All I can decide to do is write an email to the instance admin, which isn’t great.

I’d also love to see warnings/strikes. In some cases I’d love to see a comment stay there, just with an added: “User has been warned: Don’t use personal attacks in an argument.” Rather than either let it slide or straight out remove someone from an entire community as the first step.

And maybe the backend recommend temp-bans to mods. Plus maybe a change in phraseology. People in the drama communities always complain about getting “banned”, and they complain about a 2 day cooldown the same way as a forever ban.

And judging by our drama communities, I bet quite some people want a social media aspect on the moderation system as well, like up- or downvote a mod’s decision 😂

If the mod log is public, then it does make sense for there to be a “public” and “private” version, so perhaps allowing an edit of a modlog entry will change the view presented to federation and non-admins, while the original view stays immutable? This could allow the modlog to stay public.

The option to have the modlog visibility be either public | signed in | admin only is a good option as well, and a good combination for those who are concerned about doxing could be “signed in + modified view” or going straight to admin only. Another consideration could be to have the text body be admin only, but still present the mod log of username + action + reason, but without the details?

So, it could be the simplest option may be to have a flag to show details to admins only, and to not include the text in federation or to federate “details available to instance admins only” or something like that. This could be the least amount of work, possibly.

The modlog has a bunch of issues and, frankly, I think creates more problems than it solves (but I know I am in the minority in this way). The lack of a modlog hasn’t seemed to hurt other fedi projects any, just look at Mastodon. Anyway, I had originally tried to structure this comment a bit more, but it ended up kind of rambly, so I apologize.

When looking at content removals, it is especially problematic currently when it comes to comments. Lemmy includes the full text of the comment being removed in the modlog (piefed truncates the comment contents iirc). So, if the comment has doxxed info or something else where simply existing as text is an issue, then even removing the comment doesn’t solve the problem since that now just lives in the modlog, permanently, across hundreds of federated instances. At least for posts, it will just have the post title in the modlog and the link to the post won’t be accessible unless you are a mod/admin. So, just having a local way of removing that content from the modlog doesn’t necessarily solve the problem, since it will live across every other federated modlog still.

All of that happens even if the community mods and admins are all acting in good faith and doing their best to remove this content. This doesn’t even begin to broach the issue of mods/admins abusing their ability to write to the modlog (however you want to define abuse). If a mod were to do something like doxx somebody or put a malicious link in the reason field of a modlog entry…how can you handle that? Once it is in the modlog, that’s it. That has now spread to every other federated instance.

A local way of removing problematic modlog entries makes a lot of sense in some cases. As I pointed out on matrix and you have included above, certain jurisdictions might have different requirements on what is allowed speech. So, giving admins the ability to remove content in the modlog that contravenes local regulations is helping admins do their legally obligated duty. I agree that it shouldn’t just be deleted without a trace though. Having a remaining entry with placeholder text to indicate what has happened helps keep some level of transparency.

However, the local modlog removal doesn’t fix the underlying federation problem. I don’t really have a solution if I am honest. I think that you could do something like give mods the ability to mark a removal as being sensitive in some way and that hides the actual content from the modlog…but that gives an awful lot of power to mods. Also, I know some people really value the current transparency of the modlog, even if its main use by normal users (non-admins) seems to be generating drama.

Hi,

I’m relaying unruffled’s idea. I cleaned lot part from his comment. Just tell me if you don’t want any comment like these

I 100% agree modlog abuse is something that needs to be addressed.

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.

The current modlog solution doesn’t fix the issue 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, this 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.

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.

I did not realize it was visible without a login. I mean that seems kinda wierd.