Problem
Self-host instances unconditionally sync the entire gittensor Bittensor-subnet miner registry from entrius/gittensor every hour (refresh-registry), regardless of whether the operator has any affiliation with the gittensor subnet. Traced from a reported "job queue pending is high despite low traffic" incident: a live self-host box (edge-nl-01) had 18 repos registered from the subnet file, 15 of which were unrelated third-party miner repos never installed on that instance.
gittensory is broadening beyond being a gittensor-subnet-only tool. Subnet integration needs to become an explicit opt-in plugin rather than a core dependency, so a self-host operator who isn't a gittensor miner has zero footprint from it: no fetch from the subnet registry, no local tracking of unrelated repos.
Requirements
- A new
experimental: manifest block (parallel to the existing features: block), with gittensor as its first key — a namespace for future opt-in ecosystem/network plugins as the product broadens.
- Per-repo activation follows the existing
resolveManifestOnlyFeature precedence (operator env kill-switch AND explicit per-repo .gittensory.yml opt-in, no allowlist fallback).
- Self-host's
refresh-registry cron job is skipped entirely (zero outbound contact with the subnet registry) when no repo on the instance has opted in.
- Cloud/hosted behavior is completely unaffected.
Deliverables
- Engine-level manifest parsing (
experimental: block, parseExperimentalConfig/experimentalConfigToJson).
src/review/gittensor-wire.ts: the plugin's env kill-switch + per-repo resolution + a gittensorEnabledRepoFullNames helper.- Cron gate in
src/index.ts skipping refresh-registry when nothing is opted in on self-host.
.gittensory.yml docs updated (config/examples/gittensory.full.yml, .gittensory.yml.example) documenting the new block.- Tests covering both sides of every new branch.
Non-goals (tracked separately)
Scoping registry/sync.ts's writes to only opted-in repos, and migrating the several CORE features currently gated on repositories.isRegistered (fidelity repair, signal snapshots, backfill, etc.) to isInstalled instead — that's a larger, higher-risk untangling tracked as its own epic, #5016.
Problem
Self-host instances unconditionally sync the entire gittensor Bittensor-subnet miner registry from
entrius/gittensorevery hour (refresh-registry), regardless of whether the operator has any affiliation with the gittensor subnet. Traced from a reported "job queue pending is high despite low traffic" incident: a live self-host box (edge-nl-01) had 18 repos registered from the subnet file, 15 of which were unrelated third-party miner repos never installed on that instance.gittensory is broadening beyond being a gittensor-subnet-only tool. Subnet integration needs to become an explicit opt-in plugin rather than a core dependency, so a self-host operator who isn't a gittensor miner has zero footprint from it: no fetch from the subnet registry, no local tracking of unrelated repos.
Requirements
experimental:manifest block (parallel to the existingfeatures:block), withgittensoras its first key — a namespace for future opt-in ecosystem/network plugins as the product broadens.resolveManifestOnlyFeatureprecedence (operator env kill-switch AND explicit per-repo.gittensory.ymlopt-in, no allowlist fallback).refresh-registrycron job is skipped entirely (zero outbound contact with the subnet registry) when no repo on the instance has opted in.Deliverables
experimental:block,parseExperimentalConfig/experimentalConfigToJson).src/review/gittensor-wire.ts: the plugin's env kill-switch + per-repo resolution + agittensorEnabledRepoFullNameshelper.src/index.tsskippingrefresh-registrywhen nothing is opted in on self-host..gittensory.ymldocs updated (config/examples/gittensory.full.yml,.gittensory.yml.example) documenting the new block.Non-goals (tracked separately)
Scoping
registry/sync.ts's writes to only opted-in repos, and migrating the several CORE features currently gated onrepositories.isRegistered(fidelity repair, signal snapshots, backfill, etc.) toisInstalledinstead — that's a larger, higher-risk untangling tracked as its own epic, #5016.