Host a trial relay

This package lets someone else operate the finite trial service using their own server, domain and HTTPS certificate. Participants do not open router ports. The relay host needs a publicly reachable server; a home computer behind NAT is not sufficient for this hosting recipe.

The service coordinates paired discovery, relays encrypted connections, and can also run the existing single-participant discovery and private-group trials. Pair sessions themselves create no server-side discovery peer. It is an experimental, capacity-limited service, not a permanent messaging server.

Build from source

Download the source package and check its SHA-256 against the release manifest. It includes source, locked Rust dependencies, the coordinator and build instructions; no operator identities, deployment tokens or private registry access are required.

tar -xzf operator-relay-source-v1.tar.gz
cd operator-relay-source-v1
docker build -f Dockerfile.relay-service -t skein-trial-relay .

The container builds two Rust executables. Python coordinates short-lived sessions; nginx proxies HTTPS-upgraded relay traffic after your front proxy terminates TLS. These orchestration dependencies are on the host, not on participants' computers.

Deploy on your own Fly account

The package also includes relay.fly.toml. With flyctl installed and signed into your account, choose a globally unique app name:

flyctl apps create YOUR-RELAY-APP
flyctl ips allocate-v4 --shared -a YOUR-RELAY-APP
flyctl ips allocate-v6 -a YOUR-RELAY-APP
flyctl deploy --remote-only --ha=false --app YOUR-RELAY-APP \
  --config relay.fly.toml \
  --env SKEIN_TRIAL_URL=https://YOUR-RELAY-APP.fly.dev/
curl -fsS https://YOUR-RELAY-APP.fly.dev/trial/health

This provisions a paid, standing 1 GiB service in your account; no local Docker installation is needed for the remote build. Keep one service machine for this trial: pairing state is in memory and is not shared across instances. Use the app's HTTPS URL for both participants. Destroy the app when your trial is finished to stop its running resources. Independent administration on Fly tests loss of our service; choosing another provider also adds provider diversity.

Run behind your HTTPS proxy

Replace the example domain with one you control:

docker run -d --name skein-trial-relay --restart unless-stopped \
  --read-only --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 1g --cpus 2 \
  --tmpfs /tmp:rw,nosuid,size=64m \
  -p 127.0.0.1:18080:8080 \
  -e SKEIN_TRIAL_URL=https://relay.example.org/ \
  skein-trial-relay

Configure your HTTPS reverse proxy to forward this dedicated hostname to 127.0.0.1:18080. It must preserve paths and query strings, support HTTP Upgrade, and allow relay connections to remain open for at least 125 seconds. The trial service binds only to localhost in this command; expose the HTTPS proxy on the server, not the raw backend. Use a publicly trusted certificate.

Verify:

curl -fsS https://relay.example.org/trial/health

It should report ready: true and capacity: 8. Give participants your base HTTPS URL and the paired-trial instructions.

Stop with docker stop skein-trial-relay. No participant keys are held here. Restarting clears invitations, quotas and active sessions; participants must start new trials. For a finite test, remove the container and DNS entry afterwards.

Test replacement rather than just another hostname

1. Install the clients and save the paired helper before the test.
2. Use the new service URL on both participants.
3. On the test clients, block access to skeinnet-operator-trial.fly.dev with your network controls. Keep the chosen service reachable.
4. Run the pair and retain both reports. Check the relay URL, both distinct operator identities and both directions' verified-query counters.
5. Record who administered the relay and nodes, their providers and test date. Share only public reports; never send keys, invitations or session tokens.

A successful run tests independence from our runtime service. It does not establish independent protocol implementation, automatic failover or universal NAT coverage. Reports contain client assertions and need attribution. The relay sees transport identities, connection timing and traffic volume, even though it cannot read the encrypted protocol traffic.

Capacity and abuse

The service shares eight finite relay slots, bounds HTTP concurrency to 16 workers, and permits 240 relay starts per hour per process. Pair invitations have their own 240/hour bound and eight-room cap. These protect resource use; they do not prevent an attacker from exhausting availability. Keep hosting costs capped and supervise the trial. Larger deployments and multiple relay providers require further tests.