Feature request: allow operators to disable estimated node positions via configuration #315

Request

Allow the instance operator to enable or disable estimated node positions through server configuration.

An operator should be able to turn off the neighbor-derived positioning feature without modifying code. This must be more than hiding the “Neighbor Estimate (estimated)” row in the browser: the server must stop producing and exposing the affected estimates.

Why

Neighbor-based positions are approximations, not reported GPS fixes. Even clearly labelled estimates can confuse users when displayed alongside reported positions or used as fallback coordinates in packet paths and analytics. Operators should be able to choose whether their instance provides this feature.

Current behavior / related work

• Node detail currently calls the estimator and adds estimated_lat, estimated_lon, contributor count, and (where applicable) distance from the reported position. Current implementation.
• The estimator is also used for approximate packet-path positions, area/position-gap analytics, and GPS-sanity comparisons. Disabling only the node-detail row would leave other consumers active.
• PR #195 improves the quality and explanation of neighbor estimates. It is currently an open draft and does not introduce an operator on/off switch. Coordinate with that work, but keep this request separate from estimator tuning.

Proposed configuration

Illustrative naming, to be aligned with the existing config conventions during implementation:

{
  "estimatedPositions": {
    "enabled": false
  }
}

Proposed compatibility policy:

• Missing section or missing enabled: preserve existing behavior (enabled).
• Explicit true: enable the feature.
• Explicit false: disable it instance-wide.
• Document whether a server restart is required. A startup-loaded setting is sufficient for the initial implementation; live reload is not required.

The default above is a backward-compatibility proposal, not a request to switch existing deployments off automatically.

Expected disabled behavior

1. Backend enforcement. Do not calculate or return neighbor-derived position estimates, including legacy estimated_* fields and any typed metadata introduced by Make neighbor position estimates conservative and evidence-aware #195. Expose the effective policy through the existing client-config response using a typed field.
2. All consumers covered. Audit both single and bulk packet-path lookups, node detail, Areas / Position-Fix Coverage Gaps, and Suspicious GPS Positions. Remove or disable estimate-dependent output and derived distances; preserve functionality based on real coordinates. Keep packet routes and node identities even where a geographic point is unavailable.
3. Consistent UI. No neighbor-estimate rows, markers, connecting lines, or estimate-based distances on either the full node page or side panel. Estimate-dependent tools should explain “disabled by the instance operator,” not imply that no evidence or no anomalies exist.
4. No client-side bypass. URL parameters, saved browser preferences, or a customizer toggle must not re-enable estimates when the server policy is off.
5. Preserve actual data. Reported GPS fixes and explicitly configured observer coordinates remain unchanged. Do not delete node positions, neighbor edges, history, or other stored data; do not disable neighbor-graph construction or non-positioning uses of the graph.
6. No stale estimates. Audit relevant caches and shared response objects so requests in disabled mode cannot expose estimates produced in enabled mode. Document the scope of any other coordinate fallback encountered during the audit.

Acceptance criteria

• Config tests distinguish omitted values from explicit false; invalid types receive the normal config validation treatment.
• API tests cover enabled, disabled, and omitted settings, including nodes with and without reported GPS.
• Disabled mode skips the relevant estimator work/queries rather than computing results and discarding them.
• Single and bulk path responses consistently honor the policy and preserve non-geographic route information.
• Analytics distinguish a disabled calculation from a measured zero or “no evidence.”
• Frontend tests and browser validation cover the full node page, side panel, packet-path view, and affected tools, including direct URLs and saved preferences.
• Reported GPS and unrelated neighbor-graph functionality have regression coverage.
• Document the setting, default, scope, restart/reload behavior, and API contract in config.example.json and the relevant operator/API documentation.
• Preserve the server's read-only DB invariant. No new per-node API calls, N+1 query paths, or unbounded scans are introduced.

Scope / follow-up

This issue is for the operator configuration switch, not a change to estimation accuracy, thresholds, or default visibility for individual users.

Per repository rule 8, a later customizer control can be considered, but it must remain subordinate to the operator's server-side policy.

Creating this issue does not authorize implementation, a configuration change on staging/production, or a deployment.