Artifact Description [902d74b36c]

Artifact 902d74b36c23ebd4f8a67a1ab25ea0e13bf34d54f437a3f486f809bf04b068f3:

• File internal/sync/sparse.go
  • 2026-10-22 12:05:54 — part of check-in [588d5b264e] on branch feat/horizon-cones — fix(sync): chase cluster names only from horizon-ignorant origins

    The re-pinned §4.5 (zit#266) splits the cluster rule by origin. An origin that says horizon-served announces what it keeps directly, so a horizon store must not request a name only a cluster gives it. A horizon-ignorant origin, fossil(1) among them, folds 100 or more unclustered artifacts into a cluster as it answers a pull and announces only the cluster, so a new check-in may be named nowhere else: the store must request what the cluster names, as transit, and classify what arrives. A horizon store acted on no cluster from either, and so never received such a check-in from fossil.

    CrosslinkCluster now mints member phantoms in every store, as fossil does; the received-file filter already drops the cluster and the blobs below the horizon at the end of the transfer. Whether to act on a cluster is decided where the origin is known: once a reply of the session says horizon-served content, the sync client asks for no cluster catalog and the sync and clone clients store no cluster file card, so no cluster-only phantom is minted from such an origin.

    A real fossil(1) case pulls a leaf announced only through the cluster fossil makes, and holds it and its blob without holding the cluster. (user: [email protected], size: 4244) [annotate] [blame] [check-ins using]

  • 2026-10-22 14:33:38 — part of check-in [84be5ad824] on branch feat/horizon-cones — Merge branch 'wip/horizon-serve' into feat/horizon-cones

    Appendix A step 3 without the cursor: the client sends pragma horizon, the origin computes the held set over its dense graph, sends only the blobs above the horizon, inflates crossing deltas, sends no cluster, answers horizon-served content and refuses what it cannot cover (§6.4). Against a horizon-ignorant origin the client requests what its clusters name, as transit (§4.5 after zit#266). Interoperates with zit both ways. (user: [email protected], size: 4244) [annotate] [blame] [check-ins using]