Open themesh.

Privacy-redacted, copy-ready report for MeshCore issue #3302, based on public data captured September 3, 2026, approximately 20:15–20:24 UTC. MeshMapper displayed “Last Updated: Sep 3, 12:09.” Live counters change continuously, so small differences between calls are expected.

Recommendation

Create a separate Canada (Recommended) preset in every official preset surface and make 3-byte path hashes the default for newly provisioned companions, repeaters, and room servers using that preset.

The Canada preset should retain the current USA/Canada radio parameters—910.525 MHz, SF7, BW62.5, CR5—while setting path.hash.mode to 3-byte operation (2 in the current CLI value mapping). Keep manual override, do not silently rewrite existing devices, and leave the United States preset on whatever default its own readiness and operator consensus support.

The case is not “3 bytes are globally best.” It is narrower:

• Canada is materially more ready for multibyte traffic than the United States or the global network.
• One-byte path identifiers are already non-unique at Canadian regional scale and produce ambiguous route attribution.
• Current Canadian traffic and configured-device data show a large gap between capability and actual default use; a preset is the scalable way to close it.
• A 21-hop path ceiling covers the overwhelming majority of current Canadian traffic, but it is a secondary guardrail—not a substitute for flood.max* controls.

Executive evidence

1. Canada and the United States are not at the same migration point

The MeshMapper Multibyte Upgrade Board defines a repeater as multibyte capable after it has been observed handling a multibyte path or advertising a 2+ byte identifier. It counts on-air repeaters inside each region’s own boundary. Summing the underlying region counts—not averaging region percentages—produces:

Canada is 11.8 percentage points ahead of the United States and 14.6 points ahead of the global board. The national aggregates also hide a much wider US readiness spread:

Canada is not perfectly uniform—Calgary was 70.2% and Victoria 75.9%—so local checks still matter. But a single shared preset forces the more-ready country to inherit the slowest migration constraints across both countries. Two presets can keep identical RF parameters and remain interoperable while choosing different path-hash defaults.

2. High capability has not become the default

The Canadian selection in CoreScope’s hash-size endpoint reported the following configured repeater advert modes across retained observations:

Twenty-eight additional repeaters had no observed advert setting and were excluded from the percentage. This is a configuration measure, not the same denominator as MeshMapper’s capability measure.

CoreScope also showed multibyte traffic originating from every requested role: 220 companions, 1,314 repeaters, and 71 room servers were observed using 2- or 3-byte paths. These counts prove that all three roles participate in multibyte operation; they are not full role-population denominators.

Two independent traffic views both show that one-byte behavior remains dominant:

• CoreScope’s retained, non-time-windowed path-bearing observations: 68,476 one-byte, 14,438 two-byte, and 36,288 three-byte packets—57.4%, 12.1%, and 30.4%.
• BEACON’s public API, using the complete newest 24-hour slice from its packet feed: 55,959 one-byte, 6,377 two-byte, and 16,402 three-byte packets—71.1%, 8.1%, and 20.8%.

The feeds use different inclusion rules and retention windows, so their percentages should not be merged. Their common result is what matters: multibyte support exists, but 1-byte remains the behavioral default. That is exactly the sort of adoption gap a regional preset solves.

3. The primary technical reason is path identity

MeshCore’s official multibyte FAQ explains that path entries are prefixes of repeater public keys. It notes that 1-byte mode has only 254 usable identifiers after reserved values. At Ottawa–Gatineau’s 258-repeater scale, at least two full-key prefixes must therefore match in the 1-byte namespace. That does not automatically break forwarding, but it makes a path ambiguous whenever same-prefix repeaters participate in the relevant routing domain.

For a nominal hash space of size H, the birthday-collision probability for n independently distributed prefixes is:

P(collision) = 1 - product(k=0..n-1)(1 - k/H)

Using the nominal 65,536-value 2-byte and 16,777,216-value 3-byte spaces:

These are probabilities of at least one duplicate pair, not packet-loss probabilities. Their value is in showing why 2 bytes is a major improvement over 1 byte but is not a durable identity margin for a 250–500-repeater collision domain.

The CoreScope collision endpoint provides observed confirmation while separating geographic relevance:

The national observation set is not one radio collision domain. A distant duplicate does not imply a live forwarding conflict. The important operational signal is that local and regional 1-byte collisions are already present, while the observed 3-byte duplicates are geographically distant.

Longer prefixes also improve the integrity of mapping, troubleshooting, route comparison, and capacity planning. If a path entry can refer to several repeaters, topology analytics cannot reliably identify which infrastructure carried the packet. A mesh cannot tune what it cannot attribute.

4. Current topology supports 21 hops as a guardrail, not as the main argument

BEACON’s Canada-focused observation service listed 38 Canadian region codes, 30 active in its 24-hour overview, with 130 active observers. Its complete node registry returned 9,923 records; 2,092 were marked stale=false by the service:

Among the 1,719 non-stale repeaters, the service reported 12,445 neighbour references. Median known-neighbour count was 4, the 90th percentile was 18, and the maximum was 102. Those are directional observation records, not deduplicated undirected edges, but they show a dense, highly uneven topology rather than a chain with a single representative path length.

The latest 24-hour packet slice contained 78,738 packets and extended beyond the cutoff in the 100,000-row retrieval, confirming complete coverage of that window. Its latest-observer path metadata showed:

Observed maximums were 63 hops for 1-byte packets, 32 for 2-byte packets, and 21 for 3-byte packets, matching the protocol’s practical buffer limits.

This supports a careful conclusion: 21 hops covers 94.3% of currently observed path-bearing traffic, but it would intentionally exclude a real 5.7% deep-path tail. Whether that tail represents valuable reach, duplicate flood propagation, unusual RF conditions, or observer placement cannot be determined from the privacy-redacted aggregate alone. The ceiling is therefore a reasonable Canadian default and safety rail, not proof that no route will ever be affected.

5. Why the default should cover companions, repeaters, and room servers

The sender chooses the path-hash width. Official MeshCore documentation identifies companions and repeater adverts as common original senders, and the current firmware source also applies path_hash_mode when room servers originate flooded replies and messages.

• Companions: They originate much of the user traffic. Leaving companion defaults at 1 byte preserves ambiguous paths even after repeaters are upgraded.
• Repeaters: Their adverts are the raw material for topology discovery and upgrade measurement. Three-byte adverts make infrastructure attribution substantially more reliable.
• Room servers: They originate flooded replies and messages. They do not create the same relay-choice ambiguity as repeaters, but their outbound paths still traverse repeaters and should use the regional identity width consistently.

The current source paths are visible in the official companion, repeater, and room-server implementations.

6. What 3-byte defaults do—and do not—solve

They do:

• make route entries dramatically less ambiguous at Canadian regional scale;
• improve the trustworthiness of topology and troubleshooting tools;
• give new devices a consistent regional default without relying on every operator finding an advanced setting;
• impose a practical 21-hop ceiling on traffic originated with that setting;
• remain interoperable through repeaters running firmware 1.14 or newer.

They do not:

• guarantee lower airtime: each path entry is larger, and the cost grows with hop count;
• replace flood.max, flood.max.unscoped, flood.max.advert, regional scopes, or future per-hash-size limits;
• make pre-1.14 repeaters compatible—those repeaters silently drop 2- and 3-byte packets;
• prove every Canadian sub-region is ready or that every >21-hop observation is expendable.

That distinction answers the strongest objections in issue #3302. The proposal should stand on path uniqueness and usable telemetry. The hop ceiling is a welcome secondary control. Airtime policy should continue through explicit mechanisms such as flood.max*, per-hash-size flood limits proposed in #2861, and advert scheduling proposed in #1949.

7. Proposed upstream behavior and rollout guardrails

1. Add Canada (Recommended) alongside the existing combined entry in official mobile/web preset surfaces.
2. Keep the current Canadian RF tuple unchanged; set the preset’s path-hash default to 3 bytes for companion, repeater, and room-server provisioning.
3. Apply the default when a user explicitly selects the preset or provisions a new device. Do not silently rewrite existing installations.
4. Preserve the manual 1-/2-/3-byte override.
5. Keep a distinct US preset so US communities can choose their own default without blocking Canada.
6. Show the existing compatibility warning: firmware older than 1.14 drops multibyte packets.
7. Before changing a local production mesh, operators should inventory critical repeaters—especially tower, solar, and hard-to-access sites—and confirm 1.14+ compatibility rather than treating the national percentage as proof about a specific route.
8. Pair the preset with explicit flood/advert policy; do not market path width as a replacement hop-control feature.
9. After rollout, publish privacy-safe measurements for delivery/ACK success, one-/two-/three-byte traffic share, observed local collisions, >21-hop share, and airtime. Define rollback around a measured reachability regression, not anecdote alone.

8. Data-quality and privacy limits

• MeshMapper’s 84.5% is a capability statistic; CoreScope’s 56.3% is a known repeater configuration statistic; BEACON’s packet mix is observed traffic. They answer different questions and must not share a denominator.
• The public Canadian services are observer-attributed. Cross-border nodes can appear in Canadian observations, and a national list is not one RF collision domain.
• Selecting the US region codes exposed in CoreScope returned zero packets and zero nodes at capture time. That means the Canadian CoreScope instance did not provide usable US traffic/configuration telemetry—not that the US had no nodes. US comparison in this report is therefore limited to MeshMapper’s capability board.
• BEACON’s live overview and packet retrieval moved by a few tenths of a percent during capture because ingestion continued. Reported percentages use one complete 24-hour extraction.
• CoreScope’s hash-size and collision endpoints intentionally span retained data rather than the topology time window.
• No individual node names, public keys, observer identities, coordinates, exact routes, or link pairs are reproduced here. Only country-, region-, role-, and hash-size aggregates are included.

Concrete ask

Please split Canada from the current USA/Canada preset and make 3-byte path hashes the Canadian default for companions, repeater adverts, and room-server-originated traffic. Canada’s measured readiness, already-observed local 1-byte collisions, and strong capability-to-default gap justify a regional choice. Keep user override and a legacy path, pair it with explicit flood controls, and let the United States complete its own readiness discussion independently.

Source and method appendix

• MeshCore issue #3302 and comment 5531168139, captured while the issue was open with 15 comments.
• Official MeshCore multibyte FAQ and packet format.
• MeshMapper Multibyte Upgrade Board: 471 region rows parsed; country totals calculated as sums of capable and total counts.
• CoreScope: /api/config/regions, /api/analytics/hash-sizes, and /api/analytics/hash-collisions; Canadian filter was the 35 exposed XCM/Y-prefixed region codes.
• BEACON: /api/v1/iatas, /api/v1/stats/overview, /api/v1/nodes?limit=20000, and /api/v1/packets?limit=100000; 24-hour packet cutoff applied to lastHeardAt and topology summarized from the latest observer’s encoded path metadata.