[Assets] Initial implementation

[bigcat88]

This PR targets dev branch

1. Old files(Models Manager, old Assets implementation) were removed
2. Added migration with 5 tables, that should be enough for now
3. Tested only on SQLite, should work on PgSQL as well (will test later)

[guill]

When multi-user support is enabled (via the --multi-user flag), we would want to filter assets to only show:

1. Those with no owner (i.e. things we just picked up off disk)
2. Those where the current user is the owner

[bigcat88]

added in last commit. behavior:

Assets with no owner(assets_info.owner_id==``) are available for everyone for read, delete, edit.

Assets with the owner are available only for owner, but other users can create from the hash their own records in the assets_info using Create Asset from Hash endpoint.

[arjansingh]

This works for my needs. I do have some questions about the long term use of tags. See my inline comment for that.

[arjansingh]

So playing around locally:

Lora Model Asset

  {
    "id": "9afecf35-9af9-46b9-a68e-2aff1714115d",
    "name": "blindbox_v1_mix.safetensors",
    "asset_hash": "blake3:78195c5cff4c6d83a61b0d6b836d59f85efee66fbb953758e4b2af0389f8a802",
    "size": 151108831,
    "mime_type": null,
    "tags": [
      "loras",
      "models"
    ],
    "user_metadata": {
      "filename": "blindbox_v1_mix.safetensors"
    },
    "preview_id": null,
    "created_at": "2025-09-16T06:02:41.494068",
    "last_access_time": "2025-09-16T06:02:41.494068"
  }

Checkpoint Model Asset

  {
    "id": "837a544e-bf0f-427d-b586-2da83ae0c353",
    "name": "v1-5-pruned-emaonly-fp16.safetensors",
    "asset_hash": "blake3:4c50ebc6e2a5cb19e8d19626d5ede1fb64755562085ce7383d86c72d1d03eb7e",
    "size": 2132696762,
    "mime_type": null,
    "tags": [
      "checkpoints",
      "models"
    ],
    "user_metadata": {
      "filename": "v1-5-pruned-emaonly-fp16.safetensors"
    },
    "preview_id": null,
    "created_at": "2025-09-16T06:02:41.456527",
    "last_access_time": "2025-09-16T06:02:41.456527"
  }

@bigcat88 or @guill, confirm you that user_metadata.filename is the path we're going to be what we will be using for backwards compatibility.

[arjansingh]

Also for our purposes, I am having to include frontend logic to parse and categorize the different types of models.

For Example:

1. Fetch assets with tag "model"
2. For each asset, categorize them by other tags (e.g., checkpoints, loras).
3. Filter categorizes for ones I care about.

Is this intended? I could see it being fragile if we hardcode are changed or get removed. I guess the search endpoint in the future will fix this?

[arjansingh]

Okay i forgot one more thing... is "name" ever going to be user-friendly from your end?

Using name right now, most people will see something like this:

[Kosinkadink]

Since this is in a very good spot, I'll just go ahead and merge it into asset-management for easier iteration going forwards.