Why it matters
Desktop-node mirrors give ForkMesh a concrete mechanism for full Git replicas on machines controlled by users and organizations. A catalog entry can have multiple linked mirror nodes, while an external GitHub or GitLab stub never pretends to be mirrored.
Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, desktop-node mirrors 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 desktop-node mirrors through the same split it uses across the product: nodes keep real replicas, while the Worker coordinates signed discovery, HTTPS health, integrity, account lookup, and bounded clone routing.
Public repositories require a signed refs digest and content integrity checks. Private replicas are client-encrypted under per-repository content keys, stored under opaque identifiers, and re-keyed when an owner revokes a recipient. The Worker receives owner and repository names on authenticated control-plane requests and stores that metadata encrypted; it does not receive private repository plaintext. Unauthorized mirror operators receive neither the private repository name nor plaintext content.
Where it fits
Use desktop-node mirrors 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 Desktop-node mirrors keeps full bare Git mirrors on ordinary desktop nodes connected to the repository, its signatures, and the nodes that serve it.