Label context field

[chaoaretasty]

I haven't dug deep into the specs or anything nor do I know how feasible this would be. However I think it would be useful for labels to include a freetext context field (optional at the label label though potentially required for specific labels).

This would enable two key ways to interact:

First for warn settings you can display the context to have an idea of you want to click through.

Secondly it allows communities to build up unofficial taxonomies that an advanced UI could allow more fine grained control of.

These thoughts were mostly inspired for the spoiler label. On its own it's too broad to be useful but also too broad a topic to ever definite a taxonomy.

Having a mandatory freetext context means those wanting to be careful in general can warn on the label, see the context isn't a shoe they care about or are you to date on, and click through.

Likewise if the community has coalesced to say MamdalorianSeason4 and it's the only one I'm worried about I could have an advanced filter that only works on that, knowing it's imperfect but will catch most of them.

Many of the other categories could similarly do well with optional contexts, particularly around eg sexual or poem where context could help a user decide if maybe it's a link they would rather not see. Or maybe would want to filter out anything but a certain context tag (this would filter a lot out but communities again may start coalescing)

[bnewbold]

Currently labels are basically free-form tag strings, and communities could come up with their own arbitrary tag hierarchies and cultures. AO3 (archive of our own), delicious/pinboard, tumblr, and stackexchange all have interesting emergent ontologies of specific tag values.

We aren't certain if we will stick with free-form-tags for labels, or if we formalize them in one way or another to more controlled or documented vocabularies. The values we have documented in the current proposal are an initial set that we would expect virtually all clients to support.

I'm a bit skeptical of free-form text fields. They don't compose well if the situation is many labels from multiple subscribed-to labeling services all being synthesized together. There is a tension between being able to communicate very richly and being able to deliver a consistent and easy to understand experience to new accounts. I think the experience of content warnings as free-form text fields in activitypub has been pretty mixed: very successful and flexible in some contexts and communities, but difficult for new accounts or in "big world" contexts.

[chaoaretasty]

I absolutely agree on your points of the limitations of freeform text, which is why I was specifically bringing it up in the context of secondary information on the labels to give context to the label itself.

Displaying the context text for warning CTAs is still a relatively basic user experience and I think the value/user complexity payoff here is quite high.

Beyond that it's more an enabler of secondary functionality. Opening up to many individual labelling services means the various ways it could be used can be up to those various services. Maybe some will define their own sub lexicon, others might use it as a way to pass extra info to the various internal algorithms.

Secondary filtering based on community conventions is the sort of thing that could reasonably be built up by other clients or hidden behind advanced filtering UI is it's a feature that is wanted, but also just an example of the usefulness of having a second level of information where the information is too broad to satisfactorily come up with a useful lexicon.

[Heartade]

I totally agree. For example, the "spoiler" label would definitely need more context for users to know what the post spoils, while having something like "SeriesName season finale spoiler" as a label would be terrible for algos to handle.