In attempting to formulate MIME types for AI model weights like Stable Diffusion 1.5 models, or Stable Diffusion XL models, with models like PonyDiffusion being finetuned from XL, but obviously still being the same architecture and thus compatible, at least from being able to use or train it with anything that can use or train an XL model. However there is different file formats and types of weights, like .safetensors, .pt, .pth, .ckpt(obsolete), .bin, and the types are full weights: checkpoints, LoRAs, Lycoris, the more recent Dora, and then things like Embeddings, Hypernetworks etc, there is also VAE's, and then models other than text-to-image like LLMs, TTS etc.
A friend of mine posed the question to an AI about MIME typing AI models, and got this as a response:

```
Your question touches on an interesting challenge in categorizing machine learning model files using MIME types. Let me rephrase the core issue and then explore some potential approaches:

Improved description of the problem:
How can we create a flexible and future-proof MIME type system for machine learning model files that balances specificity with broad applicability, considering various file formats, model architectures, and use cases?

Possible interpretations and solutions:

1. Hierarchical MIME types:
   Create a structured hierarchy like:
   application/ml-model/{format}/{architecture}/{type}
   Example: application/ml-model/safetensors/stablediffusion/checkpoint

2. Extensible key-value pairs:
   Use a base type with extensible key-value pairs:
   application/ml-model; format=safetensors; arch=stablediffusion; type=checkpoint

3. Generic with specific subtypes:
   Use a generic type with more specific subtypes:
   application/ml-model
   application/vnd.stablediffusion-checkpoint

4. File format focus:
   Emphasize the file format, with optional metadata:
   application/safetensors; model=stablediffusion; type=checkpoint

5. Use case categorization:
   Categorize by primary use case:
   application/ml-model.text-to-image
   application/ml-model.nlp

6. Vendor-specific types:
   Allow vendors to define their own types:
   application/vnd.openai.gpt-checkpoint
   application/vnd.anthropic.claude-model

7. Append-only mapping (your proposal):
   Maintain a centralized, append-only list of MIME types for ML models, allowing for expansion as new formats and architectures emerge.

8. Combination approach:
   Use a base type with standardized parameters and an extensible field for custom attributes:
   application/ml-model; format=safetensors; arch=stablediffusion; type=checkpoint; custom={"version": "1.5", "training_data": "LAION-5B"}

9. Content-based identification:
   Develop a system that analyzes the file content to determine the appropriate MIME type, rather than relying solely on file extensions.

10. Registry-based system:
    Create a central registry for ML model MIME types, allowing for community-driven additions and updates.

Each approach has its pros and cons in terms of flexibility, specificity, and future-proofing. The append-only mapping you proposed could work well in combination with one of these approaches, serving as a reference for standardization while allowing for growth and adaptation over time.
```

I am now considering, since there is such a large variety of models and sub-models, it might be better to just type it more simply, then when processing a file as an AI model file, I can do extra checks to determine the exact nature of the model, since while there is common architecture, and a lot of similarities between models, when you factor in that you can take any two models of the same type and architecture, you can merge them together to create a new model, because of the nature of the AI brain, it can create something new that neither model knew, since it isn't like combining python code, so it isn't feasible to store all that in a MIME type, right?

So I am thinking, identify it as belonging to a AI model, then maybe identify the main architecture(ie, Stable Diffusion, or Stable Diffusion XL, or Stable Diffusion 3, or a specific LLM architecture, there is others), and maybe if it is a full checkpoint, lora, embedding, hypernetwork, etc, and leave everything else on the application to handle, because I am os.walk() to browse all files and add them to my database, I then want to determine the type of file and store that in the database(it is why I decided to go with MIME types, since it is an established standard with a python module for it), I then want extra processing to be done on the files in the database, things like generating hashes, or maybe if it is a specific type, like an AI model, I might want to see(using a generated hash) if we have all the vital info for that model, and we can pull more info from websites like Civitai if they have the model.
That is a lot of extra info I threw your way, the main thing I want you to focus on, with all this added context, I want to do the custom MIME types, I then want to be able to quickly check the MIME type on any file in the database, so I can send it to the right code location for processing, an image file(MIME: ''image/jpeg" for example), I might create a perceptual hash, and store extra image specific metadata in an image table, that links back to the file listing, however, and this is the thing you should focus on: What about when I parse my custom MIME types? Can I utilize the python MIME library for parsing?

For example, this is my helper function currently:
```
def guess_mime_type(filepath: str):
    type, _ = mimetypes.guess_type(filepath)
    return type if type else 'unknown'
```

But that is only to guess the mime type from a file, what I want now is to handle what to do with the MIME type(and also handle my custom types).