Ozone Feedback

[rudyfraser]

Now that I've been running the Blacksky Moderation Service for a week I wanted to share some general feedback about challenges I'm having in no particular order:

• If a post or account has already been taken down by the core team it shows an empty report in Ozone (handle.invalid for account, empty post text. Makes me concerned about people "dirty deleting" posts but also makes it hard to build institutional knowledge
  • Relatedly, if a user gets blocked, should be able to see the parent post a reply is under. Nuclear blocks in Ozone defeats the point.
• Not having email notifications makes it hard to scale moderation. I wrote a script for myself to do this with mailgun in a python script that runs on a loop
• How to add labels and have different translations was a bit confusing esp. with directly editing json. Would be nice to have a friendlier UX for all of Ozone.

Nice to haves

• Show comment on the queue page
• Option to turn on content warnings for reported posts with images. I had a post that showed the murder of George Floyd along with the n-word and I wouldn't have even needed to see the image to make a decision in that case.
• selecting "submit & next" would go to the next unresolved instead of the report directly beneath in the queue (I start from the bottom i.e. first in first out)

[ghost]

as a user - hiding content isnt enough for some labels, i want to block people

[bnewbold]

Thanks for the feedback Rudy!

Takendown content missing: we are working on a related feature for Ozone to snapshot content locally when reported. For us this is designed to help with deleted posts / deleted accounts, but it will help other Ozone instances with takedowns.

Nuclear blocks: I think we had that problem as well until recently, I can't remember if this was resolved via a separate API request or what. @foysalit do you know?

Email notifications: you mean getting pinged when there are new reports? We have a little daemon called beemo which can do Slack notifications, and maybe could be extended to do email, IRC, etc. https://github.com/bluesky-social/indigo/tree/main/cmd/beemo

Creating label doc: ack. could be an external tool / wizard?

Comments on queue page: Do you mean text from reports (from users), or the most recent "reason" comment when taking an action, or the most recent (or sticky) "Comment" action from another mod?

Content warnings: for images which have been auto-labeled as sexual or graphic, Ozone will blur until the image is moused over. Would it work to have a client option to enable that for all images/media?

Submit and Next: this is a simple ask! but surfaces some bigger questions about how queues should be defined, sorted, customized etc. for now I would recommend "submit" and then hit left arrow (lower-left corner or keyboard left-key). does that work well enough?

[bnewbold]

Also, while you are here, curious if you have any feedback on: https://github.com/bluesky-social/proposals/tree/main/0005-mod-history

Currently there is no way for mod services to send emails to accounts on PDS instances that the mod service doesn't have a direct relationship with (I think this option just isn't even shown in the Ozone UI if it isn't configured/enabled). The proposal would let folks see the actions taken against them, and possibly a template message about the policy violated. The whole thing would be optional, but would be good to have feedback if there are aspects that maybe should be more granularly controllable.

[rudyfraser]

we are working on a related feature for Ozone to snapshot content locally when reported. For us this is designed to help with deleted posts / deleted accounts, but it will help other Ozone instances with takedowns.

Great. Need it for both. Had a situation where I labeled a post someone later deleted but I also labeled their account which they appealed. When I went back to see the post I labeled it was gone and the only thing I had to go off of to make an appeal decision was my own internal comment.

Email notifications: you mean getting pinged when there are new reports?

Yes.

Creating label doc: ack. could be an external tool / wizard?

Could be. I found it easy to make a mistake during the process and wasn't straightforward to troubleshoot.

Comments on queue page: Do you mean text from reports (from users)

Yes. All of the options you presented could be cool if they could be toggled but I mainly mean the comment from the user report. When using Ozone in a mobile browser, you don't see the comment at all unless you shrink the window's zoom (to 50% for me) which is a problem itself. But having the comment on the queue page would help with that + prioritizing since people report things out of the scope of the moderation service.

Content warnings: Would it work to have a client option to enable that for all images/media?

Yes.

Submit and Next: for now I would recommend "submit" and then hit left arrow

I'll try it out, thanks.

Also, while you are here, curious if you have any feedback on: https://github.com/bluesky-social/proposals/tree/main/0005-mod-history

• moderation services can ultimately decide whether and how to support these APIs, though are encouraged to do so in most cases
  Feels like a strong assumption. I would only want this were it optional and configurable. I'm not interested in debating racist trolls and opening up another vector of harassment.
  Being able to let people know that something they reported was actioned is cool. I've spoken to moderators on other platforms about this "human touch" element that could be interesting to implement. Both being able to see in-app on the bsky clients (which I think increases confidence greatly) and being able to send emails. For me, under very rare circumstances I may want to send someone a message letting them know their post was labeled.

In a future iteration, it might be helpful to retain previous versions of content to display in the moderation history. For example, profile records are easily updated. If profile text or avatar image was updated in response to moderation action, it would be helpful for users to see the original record (which was actioned), and then any history of updates and the state of the record at that time, as part of the record. Similarly, self-deletion of content would be helpful to view as an event in history. Note that these events are not already stored in Ozone, and are not available via any existing service API.

This is super important for the system overall. For my purposes if at any point you said or did something that warranted labeling, it is highly unlikely that just changing that to something else absolves you. It will be confusing to end users if data isn't shown representing what it was at the time they reported it. Same for moderators as discussed above.

The specific case of a takedown at the PDS is not directly addressed by this proposal. Fetching moderation history would not directly work in that case, because the PDS would no longer be proxying API requests to other providers. In the future, we could special-case these API endpoints in the PDS, or change the semantics of what a "takendown" or "deactivated" account mean, at the protocol level, to allow certain kinds of proxied API calls. This would enable a user experience where an account attempts to log in, authenticates successfully, but no actions are allowed other than viewing moderation history and submitting an appeal in-app. This would move infrastructure takedown appeals in-app and out of email flows.

No strong opinions on this but this makes sense to me as someone who runs both a mod service and PDS. I haven't looked into what delegating moderation to a mod service from a PDS looks like since I'm still early on both fronts.

There is a trade-off with this functionality between transparency and accountability to on the one hand, and enabling bad-faith actors on the other hand. Showing more details about the timeline of moderation actions provides attackers (bot farm operators, brigading teams, harassers, etc) more information which could help them evade detection or harass the moderation service directly. Making moderation actions more transparent could also make more people aware of actions they find objectionable, especially from services they don't even subscribe to, which could stir up disputes which would otherwise have gone ignored. Running a moderation service is already a difficult and stressful undertaking.

In my eyes the negatives outlined here far outweigh the positives and are pretty on the nose. I think transparency is only owed to the reporters of a mod service. So far, mod services that act with biases or in a cliquey way have crumbled without any of this being in place.

"What should Ozone do out of the box" is an open question. Should Ozone instances default to enabling moderation history (opt-out), or should this be an opt-in feature? Leaning towards opt-in, especially for existing services.

Definitely opt-in for existing. There should be more guidance around running a mod service in general IMO and the fact that reporters will be able to see report history could be something included in that.