Node Revocation

Observe health and revoke node access

A paired node can become stale, offline or revoked. EdgeORE should show the age and source of a health observation rather than a permanent Running badge. Node telemetry is a reported observation, not a payment record or proof of useful contribution. This chapter focuses on maintaining a clear session boundary after pairing and on ending that boundary deliberately.

Read freshness

A health response should be associated with a time and the identified node. If the next read fails, preserve the last observation as stale where the UI supports it; do not keep presenting it as current. Missing disk or CPU samples should reset rate calculations rather than produce dramatic numbers from unrelated intervals. Monotonic timing is appropriate for rates because wall-clock adjustments can distort elapsed time.

Storage totals describe the host's disk, and network counters do not automatically describe customer-delivered bandwidth. A future service metric needs task attribution and verification. Do not convert bytes since boot into rewards or display a multiplier because the device has a fast connection. Current observations can inform the operator without claiming a marketplace exists.

Exercise permitted reads

Request health and any permitted public-record export under the scope granted at pairing. Confirm that a request outside scope is refused by the agent. Review exported records for credentials and private content before publishing them. An authenticated log endpoint is not permission to dump arbitrary host logs into a public evidence archive. Use the narrow protocol's intended public records.

If the node is unavailable, the app should explain that condition without pretending access is revoked. Network failure and authorization revocation are different facts. Similarly, a local session forgotten by the phone does not prove the host invalidated its corresponding authorization. The UI should explain that distinction because it affects an operator's expectations after losing connectivity.

Revoke remotely when possible

Use the supported signed revoke action and observe the agent refusing subsequent commands for that session. Capture the refusal code and time. Destroy local pairing key material according to the implementation's completed flow. A successful local button state is not enough if the remote revoke request failed. Test the offline case separately and show Revocation pending where that is the real result.

Forget locally is a useful recovery action when the node cannot be reached, but it should carry the caveat that the remote side may still need revocation. The operator may have to use another authenticated administrative path to invalidate it. Do not describe local deletion as a completed remote security action. Clear semantics are more valuable than a frictionless but misleading badge.

Preserve the result

The session note should contain node identity, granted scope, freshness behavior, revoke response and a subsequent refused read. Redact codes or material that can establish a new session. If runtime TLS or connectivity prevents the sequence, keep the gate incomplete with the actual error. A JVM integration result can support protocol logic but cannot replace this Android observation or prove unattended service reliability.

---

Wiki home · Qualification updates · Sources and credits