packets: an ambiguous path hop is shown as a single certain name, resolved without the geographic filter

[efiten]

The packets page shows one name for an ambiguous path hop, with no indication that it is a guess, and it picks that name without using the geographic filtering the resolver already implements. In the case below the displayed repeater is 185 km from the observer, while the evidence in the database points at a different candidate.

hop-resolver.js computes the ambiguity correctly. packets.js throws it away.

What a user sees

A path hop renders as a single repeater name, identical in weight to an unambiguous one. Nothing says "1 of 9". An operator reading a path has no way to tell a certain hop from a coin flip, and acts on the wrong one.

Worked case from live data

A GRP_TXT flood observed on 2026-09-30, path ["EF","E7","EE","05","7E","AE","44","38"], observed by BE-BGS-RRY120-OBS (IATA OST).

Nine nodes share the prefix EF:

node	role	distance from the transmitter	distance from OST
BE-9041-REP-VER	repeater	0.0 km	~62 km
💀RRY6710yagiPnshr	repeater	10.6 km	~55 km
BE-BLZ-WALTWILDER-EDG	repeater	126.0 km	~185 km
BE-BRE-ON8AR🔋	repeater	126.5 km	~185 km
DE-NW-D-R01	repeater	210.4 km
Dui_Rahm	repeater	211.9 km
D-WAN-Eickel (Test)	repeater	240.0 km
LDN-SM4 📡 / sapphire	repeater	280.1 km
🐧	companion	no GPS

The UI shows BE-BLZ-WALTWILDER-EDG.

The evidence available at that moment points elsewhere. The next hop in the path is E7, and of the nine EF candidates exactly one has a recorded neighbour with prefix E7:

BE-9041-REP-VER          neighbours=7    with prefix E7: 1   (BE-KOU-ON6BW-Repeater, 104 observations)
BE-BLZ-WALTWILDER-EDG    neighbours=33   with prefix E7: 0
💀RRY67~10yagi~Pnshr     neighbours=10   with prefix E7: 0

So graph affinity, geography and the transmitter's own position all agree on BE-9041-REP-VER, and the page shows the one candidate none of them support.

Root cause

public/hop-resolver.js exposes:

function resolve(hops, originLat, originLon, observerLat, observerLon, observerId)

public/packets.js:966-975 calls it with one argument out of six:

async function resolveHops(hops) {
  const unknown = hops.filter(h => !(h in hopNameCache));
  if (unknown.length) {
    await ensureHopResolver();
    const resolved = HopResolver.resolve(unknown);
    Object.assign(hopNameCache, resolved || {});

Two consequences:

1. The geographic filter never runs. observerId is undefined, so packetIata is null (hop-resolver.js:189), so nodeInRegion() is never called and regional stays empty. The REGION_RADIUS_KM = 300 filter that would have removed the German and UK candidates is dead code on this path, and the candidate list is used in index order.

2. The ambiguity is discarded. resolve() returns ambiguous: true and a populated conflicts array for a multi-candidate hop (hop-resolver.js:217-227). Object.assign(hopNameCache, resolved) keeps only what the render reads, and nothing in packets.js references conflicts or ambiguous:

$ grep -rn '\.conflicts\|\.ambiguous' public/*.js | grep -v hop-resolver.js
public/analytics.js:461, 463, 472, 2750, 3310, 3311, 3339, 3373, 3374, 3383

Analytics alone. It renders a warning icon per ambiguous edge, counts "Ambiguous Prefixes" as a stat, and offers a confidence filter that can hide ambiguous edges. The pattern this issue asks for already exists in the codebase, one page over.

3. The cache is keyed by prefix alone, so the first packet to resolve EF fixes that name for every later packet regardless of observer or region. packets.js:1001 already carries the comment // Use per-packet cache key if observer context available (ambiguous hops differ by region), so this was known.

On whether it is fixable

One byte gives 256 values for 2043 nodes, so collisions are not going away: EF alone has nine. Perfect resolution is not the goal and is not possible.

What is possible, in increasing order of effort:

1. Stop presenting a guess as a fact. Mark an ambiguous hop and show the candidate count. The data is already returned and already discarded. This alone would have prevented the wrong conclusion in the case above.
2. Pass the arguments that exist. resolveHops has the observer on the packet (observer_id, observer_iata) and the transmitter's position where known. Passing them switches on the geographic filter that is already written.
3. Key the cache per observer/region rather than per prefix, as the existing comment proposes.
4. Use the next resolved hop. pickByAffinity already scores on graph edges and would have chosen correctly here; it needs neighbouring context the current call does not supply.

Steps 1 and 2 are small and independent, and either would have produced a defensible answer in this case.

Related

The DRY point raised on #2089 applies here too: this is another site resolving a path hash prefix with its own rules. Whatever is done here should not become a sixth variant.

[efiten]

Measured the design space against live data before proposing anything. Numbers below come from the production database: 2043 nodes, the full neighbor_edges table (3322 rows), and the 4000 most recent observations.path_json values, giving 16,877 adjacent hop pairs.

Three things I assumed turned out to be wrong, so they are written down here rather than left as folklore.

The scope is narrower than it looks: this is a 1-byte problem only

prefix width	distinct values	colliding	nodes involved
1 byte	254	254	2043 (100%)
2 byte	2015	25	53 (2.6%)
3 byte	2043	0	0

At 3 bytes there is not a single collision across the whole network. At 2 bytes there are 25, touching 53 nodes, and several are self-inflicted vanity prefixes rather than chance: dead is shared by four nodes (BE-KRO-RP01 | ON1KW, BE-HAR-R-DEAD, BE-HAR-ROOM-DEAD, D-DO-Nette Repeater) and 7777 by two.

The traffic follows the same split. Of the 16,877 hop pairs:

token width	pairs	already unique with no test at all
1 byte	5,870	0%
2 byte	10,824	98.5%
3 byte	183	94.0%

So two thirds of hop tokens need no disambiguation logic whatsoever. Whatever gets built only has to be right for the 1-byte third.

What I got wrong first: "marking uncertainty would turn everything red"

That was measuring the wrong thing. Every 1-byte prefix is shared, so prefix ambiguity is 100% and useless as a signal. The useful signal is whether the evidence resolves it, which is a different number.

Using the next hop as the test — of the candidates for hop i, how many have a recorded neighbor_edges link to a candidate for hop i+1 — on the 1-byte pairs (n ≈ 5,600):

outcome	share
exactly one candidate survives	43.1%
no candidate has such an edge	54.0%
two or more survive	2.8%

Combined with the 2-byte and 3-byte hops that are already unique, roughly four pills in five would be confident and one in five marked. That is a usable signal rather than a wall of red.

What I got wrong second: a stability or bidirectionality threshold would help

It does the opposite. Requiring the supporting edge to be well-established:

threshold on edge count	resolved	no match	still ambiguous
any edge	43.1%	54.0%	2.8%
≥ 3	40.8%	57.1%	2.1%
≥ 10	39.3%	59.2%	1.5%
≥ 50	33.2%	66.4%	0.4%
≥ 200	18.0%	81.9%	0.1%

Tightening the criterion fixes the "two or more survive" case, which is already only 2.8%, and pays for it out of the resolved case, which drops from 43% to 18%. The dominant failure is missing edge data (54%), not uncertain edge data, and a stricter rule makes missing data worse. So: no stability threshold, no bidirectionality requirement.

What I got wrong third: that the resolver needs new disambiguation logic

It does not. hop-resolver.js already has pickByAffinity(), which scores candidates on graph edges against both the previous and next hop, then falls back to a geographic centroid. The logic asked for above is largely already written. As the issue describes, packets.js:970 calls HopResolver.resolve(unknown) with one argument out of six, so the resolver runs without the observer context and its ambiguous / conflicts output is discarded.

Proposed behaviour

• 3-byte hop: confident, no test.
• 2-byte hop: confident, except for the 25 colliding prefixes, which the prefix index already knows at build time.
• 1-byte hop: run the next-hop test. Confident when exactly one candidate survives; marked otherwise.
• Marked state distinguishes two cases, because they mean different things to a reader: no supporting data (54%) and several candidates remain (2.8%). "We do not know" is not the same as "these two are both plausible".
• Colour must not be the only carrier. Analytics already pairs its ambiguity signal with an icon and a tooltip; the same pattern applies here.

Bootstrapping, and a loose end worth checking

Testing hop i needs hop i+1 resolved, which looks circular for a run of 1-byte hops. It is not, because 2-byte hops are the majority and are 98.5% unique, so almost every path contains anchors to work outward from.

Those anchors are also an unused source of edges. From the 4000 sampled paths alone, 843 node-level adjacencies are derivable from hop pairs where both tokens resolve uniquely, and 293 of them are not in neighbor_edges — an 8.8% surplus over the whole 3322-row table, from a fraction of the retention window. I did not measure the full window and am not extrapolating, but it suggests the aggregate is not capturing everything the stored paths already prove. Since missing edges are the 54% that dominates the failure mode, that is worth understanding separately.

Operational note

All of the uncertainty in the system comes from nodes still using a 1-byte path hash. Moving to 2 bytes makes a node unambiguous 97.4% of the time; 3 bytes makes it unambiguous outright. That is a message for operators as much as a change to this code.