Skip to content

Support multiple Hugging Face model sources per node #273

Description

@DrHepa

Problem

A model node can currently declare only one hf_repo and one download_check. Models that depend on weights from multiple Hugging Face repositories must implement custom bootstrap or runtime downloads, so those assets cannot be installed, monitored, paused, resumed, repaired, or removed consistently from the Modly Models/Extensions UI.

Proposed solution

Add a backwards-compatible model_sources array to model nodes. The first version would support Hugging Face sources only.

Each source should declare:

  • A stable source ID.
  • A Hugging Face repository ID and optional revision.
  • A destination relative to the node model directory.
  • Optional include/skip filters.
  • One or more files used to verify that the source is complete.

Example:

{
  "model_sources": [
    {
      "id": "primary",
      "provider": "huggingface",
      "repo_id": "org/main-model",
      "destination": ".",
      "checks": ["model_index.json"]
    },
    {
      "id": "encoder",
      "provider": "huggingface",
      "repo_id": "org/encoder",
      "destination": "auxiliary/encoder",
      "include_prefixes": ["config.json", "model.safetensors"],
      "checks": ["config.json", "model.safetensors"]
    }
  ]
}

The host should:

  • Normalize legacy hf_repo / download_check fields into a single source, preserving existing manifests.
  • Resolve the download plan from the installed manifest instead of accepting arbitrary repositories or destinations from the renderer.
  • Confine every destination and check to the node model directory.
  • Download all sources through one node action with aggregate progress and existing pause/resume/cancel controls.
  • Mark the node installed only when all source checks pass.
  • Remove all node-owned sources when model weights are deleted.

Alternatives considered

Making hf_repo an array leaves destinations, per-repository filters, and readiness checks ambiguous. Keeping downloads inside extension setup/runtime code works for individual extensions, but bypasses the common model lifecycle and creates inconsistent offline behavior.

Additional context

This proposal deliberately limits the first version to Hugging Face repositories. Other providers or arbitrary URLs can be considered separately with their own integrity and security requirements.

Checklist

  • I searched for an existing request before opening this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions