cross-posted from: https://quokk.au/c/fediverse/p/887450/piefed-flagship-instance-shadowbanning-instances-from-discoverability-other-questionable-upd
This morning while checking if Quokk.au's new instance logo was federated out, I discovered that overnight we had been shadowbanned from the PieFed.Social Instance Chooser (This is a tool to help spread out users across the platform and help avoid funnelling users into the largest.)
Knowing that Rimu was happy to explain, I just asked for some clarification as we were visible on every other PieFed instance except his.
Apparently for ' obvious reasons ', of which I can only assume is our left leaning anarchist/pro-trans stance we were chosen not be advertised on the PieFed flagship instance and first point of contact for many potential new users. Seeing as a large portion of our new users found us via this method, it will have a tangible effect on a small instance such as ours.
This was a pretty sad sight to see, and reflects the sort of petty drama that is emanating from the PieFed project lately. It's now the third such move to discredit and harm left leaning instances by PieFed's lead developer. This also shows a trend towards autocratic unilateral decision-making on Piefed.social, of which is starting to be run as a personal fiefdom without consulting the team or users.
I must commend Lemmy.ml for remaining neutral and not letting its own political leanings influence join-lemmy.org, while simultaneously condemn PieFed.social for this immature move that is harmful to the health of the Fediverse.
Following this exchange, Rimu announced a new update to PieFed allowing for some rather concerning things.
- Modlog: Reason for the action is only shown from trusted instances, so abusive mods won't have an audience. Admins can still see the reason though. Which instances are trusted is set in the admin UI.
This feature means problematic users can now go undetected, and will harm moderators ability to view their past moderation history. For example PieFed.social runs a 'trusted' list of only 34 instances, meaning any mod action taken by any of the hundreds of instances outside of this will not show up. So for example if Quokk.au was to ban a user for transphobia (our most common ban), this will not be reflected for piefed.social users potentially leading towards more hate speech on the Fediverse.
- Instance silencing similar to Mastodon. A silenced instance is not defederated from but their posts do not show in the Popular or All feeds and their communities are not shown in Starter packs aka Topics. Their communities can still be found in the communities list and joined in the normal way. Once joined, posts in there show up in the subscribed feed as usual.
This is another way to shadowban instances and not 'advertise' them. Surely if an instance is problematic enough that a defederation would be in order rather than this reddit-like move.
However, you don't explain why. The extract you shared was the last part of Rimu's comment :
This person asked us, admins to remove it. Imagine that was your full name and address. We delete it and it appears in the modlog.
We can face legal issues if we aren't able to delete person real name.
Yes it was related to the ban for zionism. However that's just the tip of the iceberg....imagine a new spam bot, how will you handle it if it write in the modlog ?
I enjoy the modlog transparency. My mod action is transparent, everyone can see what we do. However there is some downside. Admins struggled to remove that person real name, that wasn't an easy task.
So there is pro and cons about the modlog. Until now, it served its purpose and allowed users to defend themselve against mod & admin abuse. However we shouldn't ignore the point above.
As for myself, i don't know what is the correct answer.
The solution isn't simple. 😔
Edit: typo
There already is an option to purge content though? Extend that as an individual admin action for individual comments? "Hiding" a modlog action doesn't make the data disappear (which makes it not GDPR compliant!), purging does. It also creates a modlog entry, "purged" that doesn't reveal the data but the action. Creating accountability that content was purged with the possibility to enter why. If the concern actually was the gdpr incident the other day (which didn't include an address dunno where that came from) the dev solution would have been to purge content have that federate, not "hide the mod entry". I don't believe that excuse at all.
This has been an extremely obvious flaw in the modlog concept from the very start, and has been discussed on and off for years. IMO, it exposes a much wider issue with federated forums as currently implemented, despite the aggressive defense of some vague concept of "openness."
Blindly casting every user and mod action out into the universe in plaintext with no recall mechanism is problematic, and it will only get more problematic as the technical prowess of the average user drops. Doxxing is just the tip of the iceberg here, and I don't think most people appreciate just how massive the social engineering attack surface actually is. Rogue instances could silently build engagement profiles on users, and then actually serve them targeted malicious content. This could be widespread, and almost impossible to detect.
I agree with your point but would nuance it. Some part are flawed but we also saw the good side of the modlog openess, let's not forget thay.
Otherwise the community yptb wouldn't exist, we wouldn't able to juge our action, user wouldn't be able to choose their own instance and that's terrible.
We already have lot power : seeing vote, ban, delete...and for me, the modlog counter-balance our tools. So i hope we can find something in the middle ground. :)
On mod tools, i think we need to developp other tool than than ban and delete, they are very aggresive. I hope we will see new tools that will change the way we take action.
I left out the context as it's literally an excuse to again limit the modlog.
The solution isn't to make it more closed off
I don't see that way. It was very difficult for admins to remove doxxing info from the modlog.
@unruffled@anarchist.nexus wanted to remove doxxing info from an user.
Our admins, together, did their best to remove the doxing info from the modlog because it federate accross the fediverse.
Given how serious the issue was, most admins expressed the idea to have an option to remove it from the modlog.
So, it wasn't only Rimu idea. Rimu is also a dev, so he decided to tackle on this issue.
The last one were Rimu was banned for zionism in a community. A false statement, He was so furious about this misinformation. Although admins from the FAF reverted the ban, the mod & modlog remained.
But, right now, what worry me the most isn't thing as "rule 2" "zionism" "rude" "bot"...but a bot that spam content throught mod action.
Yes, defederating would partially solve it, but the spam would remain...
So how i see, yes the update was the direct result of this conflict between those two instances. But this conflict wasn't the only reason, it also revealed some issues from the modlog.
Until now we used yptb, it was used to reveal mods & admins bad behaviour, Rimu benefited from it. However, we were lucky someone hasn't exploited the modlog yet.
For me, it would be a mistake to ignore it. And yes, hidding modlog from most people also raise issue for me because that's the keypart in self-managed organization and that a key part in limiting our power.
So i don't know what would be the best solution. I purposed to piefed dev a "right to answer" in the modlog few week ago in our zulip chat and maybe matrix.
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
Type 2
Type 3
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?
Edit: I realized it was missing an arrow.