โ† All blog posts

Distributed hosting

Root-commit identity

Reported mirrors can be grouped by a signed repository root commit, independent of the local name each host chose.

Feature 07 of 72FeatureDistributed hosting & preservation3 min read
Abstract ForkMesh artwork for Root-commit identity

Why it matters

Root-commit identity gives ForkMesh a concrete mechanism for grouping reported mirrors by repository ancestry rather than by whatever name a host chose. It identifies registered copies that supplied a valid attestation; it does not discover offline or unreported copies.

Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, root-commit identity addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.

How ForkMesh handles it

ForkMesh handles root-commit identity through the same split it uses across the product: nodes keep real Git mirrors, while the Worker coordinates signed HTTPS discovery, health, presence, account lookup, and clone routing.

The behavior is intentionally narrow: matching signed root commits provide a grouping signal, while current health and content-integrity checks remain separate. The Worker helps find and route a live host, but it is not canonical Git storage.

Title focus: Root-commit identity stays tied to grouping mirrors by repository ancestry rather than by whatever name a host chose and the local-first repository model.

Where it fits

Use root-commit identity when availability, clone routing, and preservation need to be handled by the mesh instead of by a single origin.

It pairs with the rest of Distributed hosting & preservation because Root-commit identity keeps grouping mirrors by repository ancestry rather than by whatever name a host chose connected to the repository, its signatures, and the nodes that serve it.