Open WithoutPants opened 4 years ago
Some people have mentioned that several studios have parent studios and some performers also have aliases how do we want to manage these scenarios?
Checksums could also be FFMPEG Fingerprints.
Some people have mentioned that several studios have parent studios and some performers also have aliases how do we want to manage these scenarios?
Performer aliases is covered in the schema above already. My suggestion would be to have a single primary name for each performer and a list of aliases as per the schema. I'll look into #115 and suggest a schema accordingly.
A decision also needs to be made about performer and studio images. I could split this off into a separate issue, but it does impact the schema.
My main concern regarding both is the possibility of copyrighted or illegal images making their way into the database. If we make the decision to allow them, then they would need to be carefully controlled. Including images also increases the storage space and upload/download throughput.
The primary name should be their real name I would imagine as that is the baseline. However in scenarios where there is no Real Name that should also be acceptable and not considered invalid.
*Edit Now that I think about the idea of a Primary name vs Secondary name that should be reasonable as well however we should have a database defined difference between the real name and aliases and then whatever their predominant or primary name is.
Regarding images. I think studio images are fine, even Wikipedia allows copyrighted logos since it's considered fair use. I also doubt any studio would object to anyone showing their logo.
Actor images are obviously more difficult. My take is that promotional images are fine, as long as we link back to the owners. I don't know specifically how indexxx and freeones solve this, but it seems something along these lines. The same logic applies for scenes, a lot of studios make cover images specifically for these kinds of purposes, like met-art, etc.
With all that said, I don't think hosting images should be a priority since there are technical issues to think through. If we just add a image_url field people can host images on imgur/vidble or just hotlink directly to the publishers, and we sidestep the entire issue.
Yes, hosting images is something I really want. I want to target here however we should consider how it should be done as it will be relevant for helping with tagging. Even if we just pull the data from someone else's database or push it through some other CDN.
ok so now that im on my pc i can port over what i talked about in discord
for performers
male `type Performer { id: ID! name: String gender: String url: String twitter: String instagram: String birthdate: String ethnicity: String country: String eye_color: String height: String measurements: String career_length: String tattoos: String piercings: String aliases: [String!]! cock_piercings: String sack_piercings: String cock_size: number in cm cock_circumstance: number in cm Head_type: String Other_cock_charactistics: String Ball_size: String sack: String
}`
for trans
type Performer { id: ID! name: String gender: String url: String twitter: String instagram: String birthdate: String ethnicity: String country: String eye_color: String height: String measurements: String fake_tits: String career_length: String tattoos: String piercings: String aliases: [String!]! cock_piercings: String sack_piercings: String cock_size: number in cm cock_circumstance: number in cm Head_type: String Other_cock_charactistics: String Ball_size: String sack: String status: String --preop postop }
Would it make sense to implement a structure for storing the types of content the performer is known to participate in?
Additionally, an enum of IDs for other major reference sources, like IAFD, might be useful.
Lifting graphql types from the original stash schema:
Performer
Notes:
Studio
Tag
Notes:
Scene
Notes: