Initial schema discussion

[WithoutPants]

Lifting graphql types from the original stash schema:

Performer

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!]!
}

Notes:

• Added gender field. This should probably be an enum of values.
• height should probably be a standardised field.
• measurements needs to be made less ambiguous
• fake_tits should probably be made into an enum (Y/N/NA)
• career_length could probably be made into two fields - start and end year
• made aliases a list of strings
• how do we handle multiple performers with the same name?

Studio

type Studio {
  id: ID!
  name: String!
  url: String
}

Tag

type Tag {
  id: ID!
  name: String!
  description: String
}

Notes:

• added description
• while the schema can be generalised, the curation of tags should be carefully controlled, in my opinion. We'd need to determine a list of (as best as possible) objective tags.

Scene

type Scene {
  id: ID!
  title: String
  details: String
  url: String
  date: String

  studio: Studio
  tags: [Tag!]!
  performers: [Performer!]!
  checksums: [String!]
}

Notes:

• added checksums. Allows multiple files to point at the one scene. May want to consider adding filename information to the checksum as well.

[Leopere]

Some people have mentioned that several studios have parent studios and some performers also have aliases how do we want to manage these scenarios?

[Leopere]

Checksums could also be FFMPEG Fingerprints.

[WithoutPants]

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.

[WithoutPants]

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.

[Leopere]

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.

[ghost]

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.

[Leopere]

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.

[iamjen023]

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
}

[Orthodox-531]

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.