โ† All blog posts

Distributed hosting

Streaming transfers

Git packs stream over ordinary HTTPS from a selected mirror through the lightweight Worker proxy; they are never retained as Worker or D1 repository storage.

Feature 04 of 72FeatureDistributed hosting & preservation3 min read
Abstract ForkMesh artwork for Streaming transfers

Why it matters

Streaming transfers keep large packfiles out of persistent platform storage. The client speaks Git Smart HTTP, the Worker verifies and selects an origin, and the selected read-only gateway streams the response through the unchanged public URL.

Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, streaming transfers 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 separates repository traffic from its multiplayer transport. Clone, fetch, raw files, standard page content, and releases use HTTPS; sockets carry only small presence, chat, movement, shared-event, and update-signal messages.

The Worker applies bounded bodies, methods, operations, timeouts, and failover. D1 holds discovery and health metadata only. The gateway invokes Git directly with hooks, credential helpers, alternate protocols, prompts, and ambient credential variables disabled.

Streaming is not permanent storage: the selected independent mirror remains the repository-byte origin, and the client-visible URL does not disclose that origin.

Where it fits

Use streaming transfers 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 Streaming transfers keeps large packfiles streamed through the relay instead of buffered in cloud storage connected to the repository, its signatures, and the nodes that serve it.