Expand labeller vocabulary

[Bossett]

Is your feature request related to a problem? Please describe.

Seeing the trouble bluesky-social/social-app#3677 is causing, and encountering issues with expressiveness in labels (like bluesky-social/social-app#3690 and bluesky-social/social-app#3354) - there is a problem in the simple tag-based approach properly expressing labeller intent - leading to all kinds of confusion.

This is going to become a big issue if there are more informational labels, as they're all going to get blended together with no sense of which ones are 'important'.

Describe the solution you'd like

I'd like an expansion of the current label vocabulary - in the label definition, it should be possible to:

• define labels as applying to accounts, posts, or blobs (to allow them to be positioned in the UI, and to give users a sense of what to expect)
• define behaviours - show, hide, label, warn, etc.; propose expanding to include a property allowing labels to be summarised (i.e. hidden behind a reveal - so the UI can just show a ⚠️ for a user to click) or not (so the UI will always show the tag) to cope with the 'scarlet letter' issue
• define more severity levels for labels to influence warning, info, etc. - these should be separate from enabled behaviours
• provide a means to indicate if a label purpose is positive or negative (which should also influence things like label colour pallette)

This can then be leveraged on the UI side to hide/show labels, put them behind reveals, etc. in a way that is consistent with labeller intent.

Something like

{
    "adultOnly": false,
    "blurs": "none",
    "defaultSetting": "warn",
    "identifier": "hello",
    "applyTo": ["app.bsky.actor.profile"],
    "appliedActions":["hide", "warn", "inform", "highlight"],
    "alwaysShow": "true";
    "purpose":"moderation",
    "locales": [
        {
            "description": "A cool description",
            "lang": "en",
            "name": "Hello"
        }
    ],
    "severity": "inform"
}

Describe alternatives you've considered

Trying to do this as a set of UI affordances is a problem as it's not possible to infer the labeller's intent in applying a label

[pfrazee]

Probably won't move on this quite yet but I figure I'll dump my thoughts and feelings.

Therapist: the complexity beast isnt real and cant hurt you

I'm actively watching the outcomes and weighing whether we need to make some additions like you're proposing. Here's how I'm evaluating the ideas:

1. New attributes which add behaviors (such as a way to indicate a label is positive)
2. New attributes which constrain behaviors (such as a way to control what a label can apply to)
3. A totally new schema shape which enshrines the emergent patterns at the cost of being more rigid

We have to be really careful about 1. Indicating a label is positive seems pretty well-justified at this point, so it may end up passing the bar, but we want to be really sure.

If a good 2 shows up, I'm interested. The system is extremely complex and anything that can reduce the complexity without dropping requirements is a win. An earlier iteration of labels had a way to specify whether a label could apply to an account or a post. We ended up removing it due to hard questions about whether the restriction broke some requirements, but the one thing I really liked about it was how it made the effects of labels easier to reason about.

In the long run, I'm watching for 3. The combinatorial nature of the current model is great for covering a bunch of cases, but it's extremely hard to predict all of the behaviors. A systemic simplification would be quite nice.

[pfrazee]

Modified the logic of when a label shows. This is the comment in the code:

The issue we have with labels on accounts is that 'negative' labels are showing everywhere, acting as a kind of "scarlet letter" punishment, when their intent is to just enable users to hide other users that are causing issues. Labelers don't have a way to express that an account-level label shouldnt show on every post.

However, there are some cases where we really do want to show the labels:

1. When the label is informational or positive (like "Verified")
2. When the label is crucial (like "Impersonation")

The solution we're applying FOR NOW is to hide severity=alert labels on accounts when looking at posts unless they're from the app's baked in moderation.

The labeling system will need to be expanded to improve this situation. See #2444

EDIT: meant to put this on the other PR but not bad to have here either.

[Bossett]

Just some final thoughts for consideration:

• I think a problem with the current implementation is that the lack of intent expressiveness leads to things like profile labels on posts in a confusing way (sometimes you want the label coming down, sometimes not). There's no hierarchy in the protocol, so any choice about how labels cascade is an opinionated one in the client. 'Render profile label whenever profile data is shown and the show-always flag is set' lets a labeller tell a client if it's ok to not render something sometimes.
• I think the approach of labelling record types lets you give users control of functions like 'blur' which is a specific UI concern (i.e. let them configure which behaviours are 'allowed'), in favour of 'this is labelling a blob, and the user has set to 'warn', therefore...' type reasoning. Consider a spider labeller - some people want to see spiders and would be interested in having that highlighted, unblurred, etc.; right now a spider labeller needs a label "spider (if you like spiders)" and "spider (if you don't like spiders)".
• Separating high-priority labels and low-priority labels is very important - I'm about to release a labeller that adds information like 'this account is <30 days old', 'this account is on list X', etc.; they are neutral in terms of opinion, and ostensibly less important than 'harasser' - but some are important on the post (i.e. 'this may be an impersonator' with age). Labelling every post seems overkill, as does artificially setting severity. The red flag for me is when I'm making 'intent' type decisions to affect a UI concern, since it makes intent unreliable - kind of like 'on a mute list' very quickly became intentless when it got used for feeds. (So positive/negative/neutral will be important.)
• Pushing further - this may let you address Downgrade untrusted label definitions social-app#3310 - because you could 'downgrade' the behaviour (i.e. hiding) and not the intent (i.e. this is really bad).

I think 'constrain first' is a good way to look at the design space (and no expectation that this goes anywhere fast), and that this will likely need extended contact with users; but wanted to get the feature request in while the current issues are fresh in my mind.