Docs / Desktop client

Developer docs

ForkMesh Qt Client

The ForkMesh desktop node is a Qt 6 application for preserving repositories and communicating with peers.

Features

Non-custodial: ForkMesh does not hold or control user funds and never stores a community member’s payout-wallet private key or recovery phrase. The first instance operator may separately keep the existing community-pool key in an encrypted local Qt signer. User-owned funds, the public community-funded reward pool, pending allocations, and completed on-chain transfers are separate states. Community rewards are optional incentives and are never guaranteed.

Build

On Debian/Ubuntu:

sudo apt install build-essential cmake git qt6-base-dev libssl-dev \
  libxkbcommon-dev libxkbcommon-x11-dev openssl
cd qt_client
./run.sh

On macOS with Homebrew:

brew install cmake qt openssl@3
cd qt_client
./run.sh

Tests

cd qt_client
./run.sh test

The smoke test covers Ed25519 identity generation/signing and room crypto.

Cloudflare setup stays local

Open Control Node in the installed ForkMesh Qt client, then use its Cloudflare deployment form. Enter a narrowly scoped Cloudflare API token only in that local desktop form. The hosted website and ForkMesh World never ask for, receive, proxy, or store the token, and a forkmesh://control/cloudflare setup link carries no token or other secret in its URL.

Review the dry-run output before deployment and clear or rotate the token after use according to your Cloudflare policy. Repository decryption keys, wallet private keys, and recovery phrases do not belong in the Cloudflare form.

Relay Mode

Start the worker locally:

cd ../cloudflare_worker
uvx --from workers-py pywrangler dev

The client starts without setup input and connects to the ForkMesh mainnode:

wss://forkmesh.com/api/repo/mainnode/forkmesh/rooms/general/ws

For local relay testing, use this server URL instead:

ws://127.0.0.1:8787/api/repo/mainnode/forkmesh/rooms/general/ws

Default rooms fetch a relay-derived shared passphrase after account or signed-node authentication. The client applies PBKDF2-HMAC-SHA256 for 210,000 rounds with the first 16 bytes of SHA-256("ForkMesh room:" + room name) as salt, producing an AES-256-GCM key. The relay controls the default passphrase and can decrypt these rooms; an explicit out-of-band participant passphrase is required for confidentiality from the relay. Persisted history is capped at 500 frames per room for 7 days.

Repository Mirroring

Click + Add, choose a local Git repository or enter a remote clone URL, and ForkMesh will run:

git clone --mirror <local-path-or-url> <app-data>/mirrors/<owner>-<repo>.git

Later syncs run:

git -C <mirror> fetch --prune

Each mirror also gets a repository chat channel so nodes can discuss project health, releases, and mirror status.

If Show this mirror on forkmesh.com is checked, the client publishes signed metadata to /api/repositories. The local source path and repository plaintext remain on the node. The mainnode receives bounded signed catalog metadata: owner, name, visibility, description, branch/head/root and served-state digests, repository counters and size, sync/host timestamps, node platform and version, channel, maintainer key, signatures, public payout and clone URLs when supplied, and bounded branding/contribution fields. A private publication additionally sends an opaque replica locator, key epoch, and encrypted-manifest hash/signature—not the local path, private repository plaintext, or recipient private keys.

Network Details