Labels !hide and !warn are taking effect even if labeler doesn't advertise them

[imax9000]

Describe the bug

These two labels are still do something and hide content when they're coming from a labeler that doesn't advertise them.

To Reproduce

Steps to reproduce the behavior:

1. Create a labeler. Do not add !hide or !warn to labels or policies.
2. Subscribe to labeler with a user account.
3. Apply label !hide to some other post or account
4. Open that post or account from the user account from step 2
5. Observe that post/account is hidden

Expected behavior

Label should have no effect. User did not consent to sourcing that label from this particular labeler, and has no way to configure the behaviour.

Additional context

Non-configurable labels that hide content are bad enough of an intrusion already. What's worse is that there's no indication at subscription time that a particular labeler can issue them and silently remove content from your feed.

[bnewbold]

@pfrazee should these labels take effect when they haven't been declared in the labels array? I can't remember if we specified/clarified behavior for the non-redact bang labels.

[imax9000]

Even if they should - users must be able to configure their behaviour, at least on non-mandatory labelers.

[mary-ext]

Here was when I asked whether clients should interpret definitions that are in labelValueDefinitions but aren't listed in labelValues, as it's somewhat related.
https://bsky.app/profile/did:plc:ragtjsm2j2vknwkz3zp4oxrd/post/3knwb2ufflk2r

Archived

[imax9000]

Reminder: this is still an issue and a deal-breaker (at least for me) for subscribing to 3rd-party labelers.

[nekorug]

I understand users not wanting a moderation service to be able to hide things without any configuration setting, but informational labels can easily clutter the configuration UI. If there was some way to specify that a label that never hides or blurs content wasn't as important and have it appear in a collapsed or hidden state in the UI, that would be nice. Because there is nothing for the user to configure, with the exception of ignoring the label, this shouldn't be an issue. I hope this is a good compromise.

[mary-ext]

Reiterating again, right now it affects local labeler-defined labels as well, and it's not clear whether they are:

1. Not ready to be used by clients (is being tested by advertising them publicly)
2. Misconfiguration on the labeler's part
3. Intended to be non-configurable
4. Intended to be hidden

I can only assume either point 1 or 2, it's a misconfiguration/not ready and therefore clients shouldn't be interpreting it, that's what I've done for Skeetdeck.

If we want them to be non-configurable or hidden, then there should be a property for this.

Point 1 or 2 also applies for global labels like !hide, the point is, it's not clear what the client should be doing here.

[bnewbold]

Now that we've had a bit of time for the labeling system to bake, what i'm leaning towards:

• for "regular" mod services (labelers), only the declared values in labelValues can take effect, and no "bang" (!-prefixed) labels should be applied by the client, even if included in labelValues
• "global" or "common" labels can be used as self-labels. The governance of this set is sort of up in the air, but for now it is just what the bsky app allows. These labels can be included in labelValues without an entry in labelValueDefinitions, but all other labels (eg, labels specific to a mod service) need to be in both labelValues and labelValueDefinitions or they get ignored. I think it is permissible to also include a labelValueDefinitions for a global/common label, which would override the global definition/semantics (eg, allow a mod service to provide their own definition of what the label means), but this is a corner-case and I wouldn't recommend doing this for now.
• the "bang" labels can be used by mod services with the "redact" flag set in local client config. these are basically "full-power" and usually mandatory labelers. the current example is the Bluesky Moderation Service in the Bluesky Social app. the pattern we expect is that apps will define a small number of "full-power" labelers (could be more than one), and that these are more tightly bound to app clients (mobile apps, desktop apps, etc) than they are to appviews. the "bang" labels are "global", and do not need to be included in labelValues or labelValueDefinitions; and actually can not be configured / overridden per-labeler. we also call the bang labels "imperative" labels: they specify a behavior, but not a reason. this can be a helpful escape hatch when there isn't a more specific label yet, or the semantics of a situation are unclear, but are less accountable or policy-driven, and are probably not appropriate for most mod services.
• we likely need some kind of notification or warning in-app when a mod service changes their labelValues or labelValueDefinitions sets. This is important so users know if additional content is now being "hidden" from their view of the network.

[imax9000]

I'm strongly opposed to some labelers receiving special treatment.

---

only the declared values in labelValues can take effect

This should apply universally, full stop. Any deviation breaks abstraction layers between clients and labelers.

"bang" labels are "global", and do not need to be included in labelValues

Please don't. You already have the power to disallow the user to turn them off. But overall it would be better if they're properly presented to the user.

"global" or "common" labels can be used as self-labels.

Your focus on making centralized service made you miss the fact that labels should be namespaced. In this case, self-label should either come with a complete definition detached from any labeler, or contain a reference to the labeler that defines it.

we likely need some kind of notification or warning in-app when a mod service changes their labelValues or labelValueDefinitions sets. This is important so users know if additional content is now being "hidden" from their view of the network.

Notification would be useful, but no content should be hidden until the user explicitly acknowledges the new label.

One way to achieve that is to disallow hiding as a default value, but that might be not always convenient for everyone.