proposed lexicons for mod report routing #3521
Conversation
lexicons/app/bsky/labeler/defs.json
Outdated
| }, | ||
| "reasonSpoiler": { | ||
| "type": "token", | ||
| "description": "Spoilers (example reason)" |
There was a problem hiding this comment.
I'm guessing (example reason) is coming later :)
There was a problem hiding this comment.
what is meant by that is the Bluesky Moderation Service won't declare or handle this reason. It is included as an example that such reasons can exist (eg, that the reason set isn't strictly 1-to-1 with bsky mod service policies, even if the "known" ones like up for the near future)
There was a problem hiding this comment.
Ah that makes sense 👍
Sorry about the tone of my comment being a little weird btw, I shouldn't have been up so late.
I really appreciate all the work you and the rest of the team are putting in to make the moderation experience better 🙏
Co-authored-by: surfdude29 <[email protected]>
| "interaction" | ||
| ] | ||
| }, | ||
| "subjectType": { |
There was a problem hiding this comment.
This doesn't seem to be used anywhere? I'm guessing the incoming report would set this or are we going to infer from the subject itself?
There was a problem hiding this comment.
the client app would use this to decide which subscribed labelers are in-scope for any particular report. it is declared in app.bsky.labeler.service. same with subjectCollections (array of NSIDs).
neither need to be included in reports because the subject type (DID vs strongRef-with-ATURI) contains the same info.
| }, | ||
| "subjectCollections": { | ||
| "type": "array", | ||
| "description": "Set of record types (collection NSIDs) which can be reported to this service. If not defined (distinct from empty array), default is bsky post and profile records.", |
There was a problem hiding this comment.
Just a gut check— will this default be a breaking change for anyone? E.g. anyone labeling lists, feedgens, etc?
There was a problem hiding this comment.
I don't believe anybody is labeling those things other than us (bsky mod team). I will update to "[...] default is any record type" to be safe though.
| "reasonOther": { | ||
| "type": "token", | ||
| "description": "Other: reports not falling under another report category" | ||
| }, | ||
| "reasonAppeal": { | ||
| "type": "token", | ||
| "description": "Appeal: appeal a previously taken moderation action" | ||
| }, | ||
| "aspect": { |
There was a problem hiding this comment.
It looks like aspect and subjectType don't use tokens while reasonType does use tokens. My interpretation of the intent there is that the aspect and subject type lists are meant to be specified within com.atproto lexicons, while reason types are meant to be extendable by other namespaces.
Seeing values like chat and video specified within com.atproto does give me some pause. I suppose the idea is that these are generic enough to apply in many settings?
There was a problem hiding this comment.
Yup, the are closer to an enum or controlled vocabulary, with definitions tied to the reporting system design. While the reason types are extensible via tokens.
In the long run, I think this reporting system should migrate to the tools.ozone.* namespace. I was tempted to try and start that with this project, but I think it is too heavy a lift for the time we have. There are some moderation things which do belong in com.atproto.* (like labeling, and probably whatever inter-infrastructure takedown delegation and inter-service reporting?), but I think this reporting API is just one take on how reporting should work, and future atproto app developers might invent different systems.
Part of updates to how mod services and clients route reports.