Node Pairing

Pair an owned node with a pinned identity

Node pairing establishes a scoped relationship with a host the user controls. EdgeORE's client uses an expiring single-use challenge, an Ed25519-signed pairing payload and a pinned TLS certificate fingerprint. This is stronger than trusting a hostname alone, but it still requires the operator to verify the fingerprint through an appropriate channel. Copying an attacker-supplied fingerprint from the same untrusted page as the endpoint does not establish identity.

Prepare the pinned agent

Use the Android repository's documented node-agent provenance and pinned artifact. Keep the upstream lineage and SHA-256 in developer documentation. Do not rename and rebuild an external dependency merely to remove its historical project name from a marketing page. The app is EdgeORE; its node agent can be a credited dependency with a separate version and license.

Build or obtain the pinned agent through the repository's documented procedure. Configure loopback exposure and the needed scopes. The historical manual pairing path uses port 9843, while integration harnesses may use a different port such as 19843. Match the actual command and endpoint rather than mixing ports from separate examples. Read the current script or help output for exact agent flags.

Reach the host deliberately

For a USB-connected device or compatible emulator, adb reverse can forward the agent's loopback port. Enter the HTTPS endpoint and independently confirmed certificate SHA-256 in the app. Obtain a fresh challenge and code, since challenges expire. Record the granted scope before pairing. A challenge that expired during setup should be regenerated, not accepted by relaxing the validator.

adb reverse tcp:9843 tcp:9843

This is port forwarding, not host authentication. The pairing protocol supplies the identity and authorization steps. Check the fingerprint shown by the agent and the one entered in the app. A mismatch should refuse pairing. Likewise, replaying a used challenge should fail. These negative checks are useful acceptance criteria because a smooth happy path can hide a weak pairing boundary.

Keep scopes narrow

Current scopes concern reading node health and permitted public-record export. They do not constitute arbitrary compute, storage rental, bandwidth relay or remote shell access. A signed request is still bounded by the agent's authorized command set. The marketing site should not display Start any job or Compute/Storage granted as if those services were already qualified.

Android TLS behavior needs runtime observation separate from JVM integration. A JVM test against the real Go agent is useful but does not establish that every Android stack accepts the certificate and algorithms. Preserve an Android pairing result with the device environment. If TLS fails, retain the exact redacted error instead of bypassing certificate validation to make the status green.

Close the pairing gate

Capture endpoint classification, pin confirmation, scope, fresh challenge result, health read and revocation behavior without publishing secrets. Test expired challenge, replay and wrong pin where feasible. The acceptance result is a scoped, authenticated session with the identified agent, not a fully functioning swarm. Any future node job dispatch needs its own sandbox, quota and service-verification design.

---

Wiki home · Qualification updates · Sources and credits