Overview of Proposals for Tagging System Improvements

[AdultSun]

The current draft from WithoutPants of Stash's roadmap includes a call to "improve the general tagging experience." This includes a wide variety of requests and concepts that have been discussed over the last few years, Not all of these proposals are created equally, and several of these approaches might not be compatible with each other. In order to prioritize these feature requests, we'll first need to back up a few steps and gain a better understanding of our options, their potential impact, and how they might compare or interact with each other.

This long post is intended to give the devs an organized master list of tag related features to work from. It also hopefully provides the community with a framework to better discuss how these requests relate to the bigger picture. Github issues for each individual feature request will still be the best place for discussing the specific details of how a particular feature should be implemented. My comments on implementation are mostly my broad interpretations of what users imagine that particular feature will look like and how it will work.

At the time of writing, not every proposal has an issue in the Github repo to track it yet and not every existing issue covers the same ideas or concerns. I've searched the repo for issues with the keyword "tag" and at least one 👍 react, but I may have missed a few. I also haven't closely read each issue and may have misinterpreted some as well.

A lot of these bullet points are some combination of my own thoughts with ideas I've seen floated in Discord at some point. I'm not even sure which of these ideas were originally my own, so I won't be able to provide the proper credit for everything. If you see one of your ideas included here either without credit or with a link to somebody else's issue, I would assume it's just an example of parallel thinking.

I've organized these proposals as best I can, grouping them into four main groups. Each group represents a different goal the underlying feature requests are trying to achieve.

---

Goals

1. Make it easier/faster to manage tags
2. Make it easier/faster to visually parse tags added to an object
3. Greater integration with Stash-Box
4. More elegant/specific/complex tag relationships

---

Feasibility

For the features that fall under all 4 goals, we must also consider the following when it comes to design and scope. We wouldn’t need a positive answer to every one of these questions, but we still need to weigh all of them to decide if the feature is suitable for Stash and how it should be prioritized.

1. What is the development cost?
   1. How much development time will this take?
   2. How difficult would it be for developers to maintain this feature?
   3. How easily can it be broken up into multiple iterations? In other words, would it need to be completed all at once as one big development project before it can released?
   4. Would this be better suited as a plugin instead of core functionality?
2. How well does this feature address both casual users and power users?
   1. How many people will use this feature?
   2. How difficult would it be for users to engage with this feature?
   3. What is the barrier of entry before benefitting from this feature?
   4. How easy is it to ignore this feature? In other words, will users be forced to engage with this feature?
   5. How well would this feature scale for extremely large datasets?
3. How compatible is this feature with other design goals?
   1. Would it make it more difficult / impossible to add some other feature?
   2. Would this add too much clutter to the UI?
   3. Does this fit within the scope of the Stash project?

---

1. Make it easier/faster to manage tags

Most of these feature requests are to make things easier for power users trying to manage large tag sets. The key here would be to prioritize the features that would give us the most “bang for our buck”, meaning features expected to be useful to a large section of Stash users for minimal dev time and resources.

We also have to consider that there are drastically different usecases even within that set of power taggers, including some users who rely entirely on scraping tags and others that rely entirely on manually adding tags. Providing flexible features that users can pick and choose as they like, using features in combination to create a workflow customized to their personal needs, will go a long way towards serving this wide range of usecases.

Another concern is to make sure that these expanded tools for power taggers does not make things more difficult or confusing for casual taggers, ensuring that minimal engagement with the tag system remains just as convenient as it is now.

Often these requests are looking for ways to make the process for finding and adding tags to an object more convenient than the current system, including improvements to organization, faster input methods, and clearer communication from the UI to the user.

• Object-specific / contextual filters
  • Hide tags that only apply to images when tagging a scene, etc.
    • Could function as a multi-select option within each tag, similar to assigning link types in Stash-Box to apply to scenes/studios/performers:
      #1253
      • This approach could be straightforward for casual taggers but tedious for power taggers
    • Could function as a filter dialog for each object type, specifying rules for including/excluding tags based on category, parents, regex, etc.:
      #4306
      • This approach could be convenient for power taggers but confusing for casual taggers
  • Could greatly reduce the number of tags in the dropdown list
  • Hide individual tags from dropdown select list that merely describes its sub-tags, like the defacto category tags that some people currently use
• Collapsible tag categories (dupe with goal no. 3):
  #3469
  #3711
  #4156
  • Reduces overall list for large tag sets
  • Groups similar tags together to find them more easily
    • Possibly divides dropdown list into columns, or adds custom prefixes like JuiceBox’s emoji system
  • Easier to tell at a glance if tags from a category have been completely covered yet or not
  • Many currently use high-level parent tags as categories, could theoretically co-opt this usecase by adding these new features to parent tags, possibly unlocked by an “is_category” flag
• Improvements / alternatives to current single-click dropdown list for editing attached tags
  • Becomes unwieldy with large tag sets
  • Improve autocomplete / search when typing, currently sorted alphabetically despite exact matches to a keyword:
    #4342
    #3180
    • Would apply to other fields as well, like selecting performers or studios
  • Introduce alternate sorting methods, like “frequently used” or “favorited” tags to the top:
    #3313
    • Tags can also be “pinned” using sort names, detailed under goal no. 2
  • Copy-paste tags in bulk, would need to define delineator (comma separated, etc.):
    #1296
    #2591
  • Multi-select checkboxes makes it easier to quickly select several tags next to each other at once and see what is / isn’t added yet, particularly useful when tags are grouped by category:
    #3711
• Greater control over scraping tags:
  #1599
  #2651
  • Current functionality within scrape dialog is to either keep current tags or replace with scraped tags
    • Scrape dialog has same limitation with performers
  • Only possible to merge current and scraped tags by using the Scene Tagger
• Display which categories are not yet covered within an object
  • Warning flags could pop up above tag edit box that say “Orientation tags not present”, “Age Group tags not present”, etc.
  • Functions as a checklist to make sure basic attributes of an object are described with tags
• Suggest / inherit tags attached to related objects:
  #88
  #696
  #2349
  • Quickly add performer-attached tags into a related scene, scene-attached tags into a gallery, gallery-attached tags into an image, etc.
  • Not all tags attached to related objects will be relevant / accurate, so dangerous to assume a blind import from one object to another will be helpful
  • Temporal performer tags and performer-specific scene tags would allow for smarter importing, for example suggesting Brown Hair instead of Black Hair based on scene release date, or knowing to inherit Brown Hair into a scene and attach it to Performer X instead of Performer Y
  • System can be expanded by adding ability to attach tags to new object types, i.e. studios and movies / groups:
    #1287
    #2497
• Suggest / inherit tags based on relation to other tags
  • Quickly add all of a tag’s parents / sub-tags
  • Custom if-then operations, “If Tag X+Y is present, then add Tag X and Tag Y
    • Possibly driven by generalized tag relations instead of explicit parent / sub-tag hierarchies
  • Suggest tags commonly used together, like BBG and DP
• Visual management of tag hierarchies
  • Drag and drop nodes to add parents / sub-tags
  • See network of tags and their relationship to each other:
    #1732
    • Easier to identify tags that are missing connections
• Most Stash-Box integrations listed under goal no. 3
• Misc. new features:
  • List view / table view for tags:
    #773
  • Weighted importance for tags attached to an object:
    #2973
    • Unclear to me what benefits this would provide within Stash, but an upvote/downvote system for tags in Stash-Box is a popular request
    • Possibly used as an alternate sorting method?
• Misc. bug fixes and oversights
  • Mass edit dialog for tags:
    #1836
    #3231
  • Create new tags within parent / sub-tag select field:
    #2736
    #3694
  • Display details on hover within select field:
    #4320
  • Tag select field loses focus after using it to create new tag:
    #3998
  • Broken keyboard shortcuts:
    #2833

---

2. Make it easier/faster to visually parse tags added to an object

Large lists of tags attached to an object make it hard to tell at a glance what is or isn’t there. Without applying additional organizational concepts, alphabetically sorted tags become increasingly difficult to read as the list grows larger, easily overwhelming users with a big set of undifferentiated information. This is especially apparent in views that summarize the tags attached to a particular object, becoming a blob of tag pills that cannot be easily parsed for information.

For some users, the answer to this problem is to limit themselves to a smaller set of tags that are important to them. But for others, it’s difficult to give up on the greater level of specificity created by a larger tag set. The answer is to give users a greater amount of control over how to organize and break up those big blobs of tags.

Many of these features can already be implemented using a custom userscript, originally developed by peolic and expanded by Maista. This means that unlike the features listed under other goals, we already have users who are familiar with a working prototype that combines these systems together. There will be less guesswork involved with knowing what these features will look like, how they will work together, and what their benefits will be.

If these new fields and concepts can be added to Stash-Box as well, it could benefit both Stash users and Stash-Box editors. Contributors could edit object-attached tags in a Stash-Box more easily by using these same organizational concepts to break up the tag blobs. Meanwhile, users could benefit from the Stash-Box’s chosen organizational system of categories, sort names, colors, etc. by scraping them into their local Stash.

• Sort / display names for tags / categories:
  #3108
  • Customize sort orders without impacting tag length or readability, i.e. Brown Hair instead of Hair - Brown or p1_haircolor. Brown Hair
    • Both tags and tag categories could have the option for sort names. Sort names for categories allows grouping similar tags together in lists and summaries, while sort names for tags allows for reordering tags within those categories.
  • Knowing what general location a type of tag can be found makes it much faster / easier to parse long dropdown lists and large tag blobs
• Color-coding tags / categories:
  #3200
  • Easier to spot where groups of tags start and end, best for large categories like Performer Tags vs. Scene Tags vs. Action Tags
  • Used to indicate a suggested action or status, i.e. red for tags that need to be replaced with a more specific variation or yellow for tags that describe if a scene has been processed by a particular plugin
• Hide individual tags from summary views:
  #2633
  • Hides redundant tags, like Brown Hair in addition to Brown Hair (Female)
  • Hides tags that are helpful for custom filters but may not be helpful in the summary blobs, i.e. tags that describe status in a Stash-Box, source of the download, drive location of the file, etc.
  • Allows Stash-Box contributors to add / save tags that they aren’t personally interested in without cluttering their local tag blobs with irrelevant information
  • Could be implemented as a checkbox that says “hidden” when editing a tag or could use a similar filter system as described under “object-specific / contextual filters” from goal no. 1

---

3. Greater integration with Stash-Box

The Stash-Box side of things is currently underdeveloped for tags compared to other object types in Stash. The lack of StashIDs means any transfer of tag data up to a Stash-Box or down to a local Stash must rely too much on guesswork.

Like other areas of the software, there are also notable features present in Stash that are not available in Stash-Box and vice versa. Closer alignment of the two feature sets will allow for both local Stash users and Stash-Box editors to more easily share their work with others and benefit in kind.

• Add StashIDs to tags:
  #2643
  • Ability to customize local tag names without breaking draft submissions
    • Drafts match tags based entirely on Stash-Box names and aliases, so custom local names can break matches
  • Ability to submit same tag to multiple Stash-Boxes with differing names/aliases
  • Possibly update local name, aliases, description, etc. to stay synchronized with changes made to the same tag in a Stash-Box
• Scrape tag info from Stash-Box
  • Easily benefit from the organization work of others, including current fields (names, aliases, description) and future fields (categories, images, hierarchies, object filters, sort / display names, color coding, etc.)
  • Submitting drafts to create / update tags in a Stash-Box would also make it easier to share that work with others
• Add tag hierarchies to Stash-Box
  • Organizing hierarchies can be confusing and time intensive, scraping them from a stash-box lowers barrier of entry for casual taggers
• Add tag categories to Stash (dupe with goal no. 1)

---

4. More elegant/specific/complex tag relationships

The following feature requests represent more radical changes to the current system for tags. Most of them expand the amount of information that a single tag can provide, often by deepening their relationship with other parts of the database.

Because most of these ideas require a great deal of change from the current system, compatibility is a primary concern. Not every idea is easily compatible with each other, with Stash-Box, or even with current features of Stash. More-so than with the features listed under earlier goals, the decision to walk through one door will require closing off others.

As noted earlier, these are the features expected to fall under the “long-term” section of the roadmap. They are also the most likely to require a higher amount of development time to complete, most likely to be difficult to break up into smaller iterations, most likely to benefit only a small set of power users, and most likely to risk alienating casual users.

• Tag attributes / meta-tags / namespaces:
  #3400
  • Splits tags into component parts, i.e. Wet T-Shirt becomes Wet → Shirt:
    #3000
  • Automates parsing of scraped tags without adding unnecessary and unorganized bloat to tag list
  • Allows for hyper-specific tags without tag bloat, i.e. covering types of hair like Long → Brown → Hair by creating two lists of color (Brown, Black, etc.) and length (Long, Short, etc.) descriptors for hair instead of creating a tag for each combination (Long Brown Hair, Short Brown Hair, Long Black Hair, etc.)
  • IIRC, I’ve been told that this is very similar to the “namespace” system that many hentai-focused image boards use to track massive sets of hyper-specific tags
  • Depending on implementation, wouldn’t be easily compatible with many suggested or existing features, including hierarchies, categories, tracking sources, Stash-Box integration, etc.
    • Alternative designs include smarter post-processing in scrapers to split up tags into their components, or to save dictionaries that recognize synonyms like Big and Large to limit the number of necessary aliases
• Performer-specific scene tags with relevant filters:
  #3281
  • Clears up ambiguity of multiple performers, i.e. filtering for Performer X + Brown Hair can return false positives if Performer X actually has blonde hair in a scene alongside Performer Y who has brown hair
    • Imperfect workaround is gender-specific tags like Brown Hair (Female), would not be necessary under this new system with ability to filter for a Brown Hair tag attached to a female performer
  • Depending on implementation in the UI, could also help to break up large tag blobs (explained under goal no. 2) by separating object-attached tags into separate buckets for each performer. Tags that aren’t specific to any particular performer can be left in a bucket that applies to the whole scene/movie/gallery/etc., which would be used as the default for migrations and scrapes.
  • There’s a Stash-Box feature request for flagging performer cameos, meaning labelling a performer’s appearance in a scene as “non-nude”, “non-sex”, “body double”, etc. This concept could be combined with performer-specific scene tags since they function very similarly.
  • Could also be accomplished with the ability to add performers to markers, see the “temporal tags” point below
• Temporal tags (start-end timestamps / dates)
  • For performer-attached tags, used to track attributes that change over time like hair styles and body types
    • Could be used to make a smarter mechanic for inheriting / suggesting tags from an attached performer to a scene (see bullet-point under goal no. 1), knowing both the release/production date of the object and the window of time certain tags were relevant to that performer
      • If scene-attached tags are performer-specific, that also means tags and their relevant time ranges could be inherited / suggested from the scenes up to the performer
    • Could also allow for smarter filters, i.e. being able to differentiate between performers who may have had Brown Hair and Long Hair at different times vs. performers who actually had long brown hair at some point in their career
    • A similar feature request was for temporal ranges assigned to individual tattoos, though that would work better with unique strings instead of tags
  • For scene-attached tags, this is essentially the Markers system
    • If performers and end times are added to markers, this would essentially provide the same data as the “performer-specific scene tags” feature at the same time. The UI would just need to display which marker-tags include which performers.
      • Creating a quick and easy way to create markers that encompass an entire scene would also help turn the Markers system into “performer-specific scene tags”, i.e. a scene-long marker could be created for Performer A with the tags that are only relevant to them (hair color, body type, etc.) while another scene-long marker is created for Performer B with their separate personalized set of tags
    • Markers are already a way to group tags together, implying that they are simultaneously true and possibly related to each other. This could also fulfill some of the function that the “tag attributes” feature provides. For example, a marker with both Wet and T-Shirt could be used to mean the same thing as Wet T-Shirt, where-as the same two tags applied to an entire scene aren’t necessarily related to each other.
      • This would require discipline in how a user constructs their markers because a single marker describing a performer with wet hair and a dry t-shirt could be tagged with Wet + T-Shirt + Hair, running into the same problem as scene-wide tags.
    • As evidenced by the above bullet points, an approach that builds on the existing markers system could result in a particularly flexible and powerful set of features that combine benefits from the two previous ideas. However it also risks overwhelming casual users who want to create simple markers/tags and aren’t interested in these expanded features. A lot of thought would need to be put into the implementation to ensure that it doesn’t overcomplicate more simple usecases. I expect that the UI design will be the key to its success or failure.
• Track providence of tags
  • Track source of a tag’s addition to a particular object, i.e. manually added, pulled from Stash-Box X, or scraped from Studio Y
    • Could also save original tag name: “Scraped from Studio Y as Tag Z"
    • Could also allow mapping of scraped tags to one or multiple local tags:
      #1463
  • Track source of a tag’s creation, i.e. pulled from a particular Stash-Box or custom made and defined
    • Could also include tag’s name at that source: “Named Tag Z on Stash-Box X”
  • Filter for tags from particular sources, for example filtering the full list of tags for only tags from Stash-Box X, filter for scenes with Tag Z scraped from Studio Y, or filter the dropdown select / tag blob to only manually created tags
  • Possibly separate tags into two different buckets of “manual / local” or “scraped / external”, similar to early suggestions for Stash-Box tags

[elkorol]

I think a good feature especially, with tag categories and hierarchies and in, relation to pulling and updating tags from Stash Boxes would be for Stash to be able to add auto migrations to the db to add tables of scene relationships, categories and tags per stash box. As, these hierarchies and categories etc, may vary from Stash Box to Stash Box. But a user may want both sets or hierarchies and the ability to switch between them. If an endpoint is dropped, also the option for a migration to drop the table.

Maybe that would pollute the table though

With the rise of AI auto tagging it would be good if a tag > scene > this tag for this scene has been tagged by AI and awaiting human verification. To be able to separate and not pollute manually curated scene, performer etc tags.

When it comes to updating tags with Stash ID's against a StashBox it would be ideal if aliases could also have a stash Id, so if they are renamed you don't end up with orphaned aliases and newly populated renames. And an option not to update and rewrite and aliases that don't have a Stash ID and are manually curated.

If making a tag update page, well I used a script to populate my Stash with tags from StashDB. But I already had manually made ones with aliases. So the script didn't populate some of the tags because they were already taken up. It took me a while to notice I didn't have these tags, or the aliases were already consumed elsewhere.

So in pulling and updating a tag from StashDB it would be good if it could detect local conflicts to the tag in question to be updated. Like if the tag name already exists as an alias elsewhere, or any of the tags that are to be updated, the aliases are used elsewhere and an option to rectify that according to Stash tags or keep as is.

Also, I'm just an English speaker but maybe introducing a multi-lingual system in intl so the community can translate tags to different languages. Perhaps locally in the db, the tags table could have a column with json data of these translations and which language each is from. Particuarly useful if a user has foreign porn and they quickly, want to switch and auto tag so they can capture foreign tags from foreign video titles.