Enhanced Custom Field Types Currently, custom fields are mostly limited to simple text in the GUI. I would like to see native support in the UI for creating:
Checkbox / Boolean: For binary attributes (e.g., “Face Revealed”).
Single Select (Dropdown): To choose from predefined options.
Multi-Select: To assign multiple specific attributes from a controlled list (e.g., “Platform Source”, “Tags for specific body features”).
Number/Rating: Dedicated fields for custom scoring algorithms.
Ability to Hide or Disable Default Fields The default fields like Hair Color, Eye Color, Ethnicity, Weight, and Height are often irrelevant for certain types of databases.
I propose a setting to toggle the visibility of these hard-coded fields in both the Edit Performer page and the Performer Details view.
This would allow for a much cleaner and more focused user interface, similar to a custom CMS or a personal knowledge base (like Obsidian or Notion).
Dynamic Display on Cards Allow these custom fields to be optionally displayed on the Performer/Scene cards or headers, similar to how tags currently appear.
For users managing private “gravure” or “influencer” databases, the current metadata set is outdated. Users often need to track specific details like “Social Media Platform”, “Face Reveal Level”, or “Team/Organization” using structured data rather than just flat tags or long-form notes.
I think it would be great to have better types for performers: especially for lgbt porn and stuff. Personally, I’m gay so important fields would be sexual orientation, position (top or bottom), type (twink, twunk, etc).
I would say that the best way to do this would be to create an abstract type system for performers, and each performer can have a collection of traits (like a class implementing an interface). Each trait defines a specific fields or even requires others traits or specific field values. It’s really hard to design a good type system, but having one would put stash on a next level. Even from a search point of view that would simplify things as the missing fields are not a problem as much.
A small example I can think of [please don’t roast me for political correctness of this example, its just an example for demponstration purposes]
Traits List:
Trait Name
Fields
Existing Traits
Requirements
Penis
length, Circumcised, girth
Tits
size, fake
Ass
shaven hole, bubble
Vegina
<I’m too gay to fill this out>
Death
date
Born
date
tattoo
tattoo-list
Orientation
fucks_with subsetof {men, women, etc}
Man
Penis, Ass
::gender=man
GayPosition
top / bottom
Man
men in (Orientation::fucks_with)
Women
Tits, Ass, Vegina
Gay
Man
{men} == (Orientation::fucks_with)
BiMan
Man
{men, women} == (Orientation::fucks_with)
GayType
twink/twunk/bear/ etc.
Gay
These are just ideas, but that could be very helpful. I can explain / elaborate more on such a design if needed. It would also be helpful for hidden fields and for things like “influencer” databases, as all fields would fully namespaced too. And it makes querying much easier and UI elements richer and easier to implement as UI elements can be implemented per trait / customized for specific traits.