โ† All blog posts

Distributed hosting

Presence done right

Bounded heartbeats, expiry, and live probes reduce stale presence while allowing the deliberately minimal real-time layer to lag.

Feature 10 of 72FeatureDistributed hosting & preservation3 min read
Abstract ForkMesh artwork for Presence done right

Why it matters

Presence done right uses heartbeats, expiry, and probes so routing decisions have recent evidence. Presence remains generalized and eventually consistent; it may lag a disconnect until its freshness window or probe completes.

Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, presence done right 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 presence through the same split it uses across the product: nodes keep real Git mirrors, the HTTPS router handles repository bytes, and minimal sockets carry generalized presence and small collaborative events.

The behavior is intentionally narrow: a routing request rechecks eligible health instead of treating a presence dot as proof. The Worker helps find and route a live host, but it is not canonical Git storage.

Title focus: Presence done right stays tied to using heartbeats, expiry, and probes so routing decisions reflect reality and the local-first repository model.

Where it fits

Use presence done right 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 Presence done right keeps using heartbeats, expiry, and probes so routing decisions reflect reality connected to the repository, its signatures, and the nodes that serve it.