Test two nodes together

This trial connects two participants' nodes. Each queries the other and verifies a signed discovery result. The service exchanges their public introductions and relays encrypted traffic; it runs no discovery node for this session.

Start a pair

Both participants need macOS (Apple Silicon or Intel) or Linux x86_64, curl and tar. The script installs the same checksum-pinned Rust client as the ordinary operator trial. No Docker, compiler or port forwarding is required.

The first person runs:

curl -fsS https://skeinnet.org/operator-pair-v1.sh -o skein-pair.sh
sh skein-pair.sh create

Send the displayed invitation privately to your partner. Within three minutes, they run:

curl -fsS https://skeinnet.org/operator-pair-v1.sh -o skein-pair.sh
sh skein-pair.sh join INVITATION

Keep both terminals open. After pairing, each node runs for 90 seconds, then stops and writes skein-pair-report.json. Share that report and any setup feedback. An existing report is not overwritten; move it or set SKEIN_TRIAL_REPORT to a new path. Identities stay in the existing local operator directory. Do not run the ordinary trial and a paired trial simultaneously using the same identity.

An invitation admits one partner. Treat it as a temporary secret; it does not prove who holds it. The service pins the two enrolled identities in their plans, and the native clients verify introductions, signatures, scope, expiry and relay.

Use someone else's relay service

Both participants set the same independently hosted service address:

SKEIN_TRIAL_URL=https://relay.example.org sh skein-pair.sh create
SKEIN_TRIAL_URL=https://relay.example.org sh skein-pair.sh join INVITATION

Run these commands on the two separate computers. There is no fallback to the project's coordinator or relay. Once the client is installed, its runtime needs only the chosen service and ordinary DNS/TLS infrastructure. A fresh installation still downloads the client from skeinnet.org; an operator can distribute the verified release files separately if that site must also be unavailable.

See Host a trial relay for the source package and hosting instructions. The report includes the selected relay address.

For seed loss, publisher loss and relay cutoff/replacement scenarios, use the decentralization test suite. Its native path needs no cloud account or Docker; the advanced source suite uses Docker.

What the result establishes

A passing report means both clients report a verified outgoing query and a completed incoming query. These are diagnostic reports, not signed execution certificates. The service cannot establish that people are independent, that their software is unmodified, or that every submitted counter is truthful.

Two people controlling their own nodes and keys can test separate node operation. Share the report and a short description of the setup. Repeating it on a separately administered relay tests infrastructure replacement. Our own staging runs establish neither independent administration nor resistance to malicious relays. This remains a synthetic discovery test, not private chat, sustained load, automatic relay failover or unrestricted network membership.

Limits and failure behavior

There are eight waiting/result rooms and 240 new invitations per service process per hour. A waiting invitation expires after three minutes. Pairing consumes one of the existing eight relay slots, shared with ordinary and private-group trials; each relay lasts at most 120 seconds. Both nodes must start promptly after joining. Requests are bounded to 4 KiB. Session capabilities and introductions stay in memory; restart invalidates them. An absent partner, full service, bad introduction or expired session produces a refusal or timeout, never a fabricated success.

Test commands:

python3 scripts/test_operator_pair_coordinator.py
python3 scripts/test_operator_pair_live.py --url https://YOUR-SERVICE \
  --binary /path/to/skein-operator --output outputs/paired-trial

Release checks

Native Mac and isolated Linux pairs passed through the staging HTTPS service. The Linux containers disabled the production service hostname. Public pairing, a clean download/install pair and the existing single-operator trial also passed. The standalone hosting source builds successfully. See the release evidence. All these checks were project-run; a later user-and-friend pair also passed. Testing with an independently operated relay remains outstanding.

If one side rejects an introduction

Keep both computers' date and time synchronized. A sender timestamp ahead of the receiving clock is rejected, even if the difference is only one second. An expired introduction is also rejected. After correcting a clock, start a new session with a new invitation.

The published v2 clients group these failures under introduction policy, scope or expiry. The source now distinguishes future timestamps, expiry, scope mismatch, unsupported versions and relay policy. These diagnostics do not relax validation; updated native downloads have not yet been released.