Thanks for the report! This is a valid gap — the MeshCore protocol already supports 2- and 3-byte path hashes at the wire level, but the Define Path editor is currently hardcoded to 1-byte hashes only.

Analysis

Current State

A MeshCore forwarding path (out_path) is a chain of routing hashes — one per hop. The firmware supports three hash widths, encoded in the top 2 bits of the outPathLen byte:

Width	Encoding	Hop format	Example path
1 byte (default)	`rawLen >> 6 == 0`	`"a3"`	`"a3,7f,02"`
2 bytes	`rawLen >> 6 == 1`	`"a37f"`	`"a37f,02b0"`
3 bytes	`rawLen >> 6 == 2`	`"a37f02"`	`"a37f02,c0d1e2"`

MeshMonitor's backend already decodes this field (hashSize = (rawLen >> 6) + 1 in meshcorePacketDecode.ts) and formatOutPath() in meshcoreNativeBackend.ts accepts a hopHashBytes: 1 | 2 | 3 parameter — so the plumbing exists. The gap is entirely in the UI and API validation layer, which the developer intentionally scoped to 1-byte with a "revisit if multi-byte hashes become common" comment in meshcorePath.ts.

The benefit of larger hashes is reduced collision risk on dense networks — with 1-byte hashes, two different repeaters could share the same routing byte, causing ambiguity.

Proposed Implementation Plan

1. Data layer — surface hash width from the companion

When the companion sends a ContactWire, the outPathLen byte already encodes hash width. Currently only hopCount is stored; we need to also store pathHashBytes.

Migration (097): Add path_hash_bytes INTEGER NOT NULL DEFAULT 1 to meshcore_nodes (SQLite/PG/MySQL).
meshcoreManager.ts: When decoding ContactWire, extract pathHashBytes = (rawLen >> 6) + 1 and persist it.
API response: Include pathHashBytes in the /contacts list response so the frontend can read it.

2. Backend — update route validation

PUT /api/sources/:id/meshcore/contacts/:publicKey/out-path

Accept an optional hashBytes: 1 | 2 | 3 field in the request body (default 1 for backward compatibility).
Update parseHexPathChain() in meshcoreRoutes.ts to validate that every hop is exactly hashBytes * 2 hex characters (e.g., 2 chars for 1-byte, 4 chars for 2-byte, 6 chars for 3-byte).
Persist hashBytes to the new path_hash_bytes column.

3. Frontend — `meshcorePath.ts` utilities

Update utility functions to be hash-width-aware:

hopByteForKey(publicKey, hashBytes) — extracts the first hashBytes * 2 hex chars from the public key.
parsePathHops(outPath, hashBytes) — validates each segment is the right length.
resolveHop(byte, options, hashBytes) — matches on the right prefix length.
repeaterHopOptions(contacts, hashBytes) — builds options using the correct hop byte.

4. Frontend — path editor modal

In MeshCoreContactDetailPanel.tsx:

Read contact.pathHashBytes (or default to 1 for existing contacts).
Add a "Hash width" segmented selector (1 / 2 / 3 bytes) visible when the editor is open.
Update the custom-byte input validation regex: 1 → /^[0-9a-f]{1,2}$/, 2 → /^[0-9a-f]{1,4}$/, 3 → /^[0-9a-f]{1,6}$/.
Update the "pick from repeater" dropdown to use hashBytes-aware hopByteForKey().
Show a note: "Use the same hash width as your network's repeaters. Most networks use 1-byte (default)."
Include hashBytes in the PUT request body.

Questions / Clarifications

Network-level negotiation: Does your companion/repeater firmware actually negotiate a specific hash width, or do you manually configure it? If the companion reports the hash width per-contact in the outPathLen byte, MeshMonitor can auto-detect and pre-select it for you.
What hash width are your repeaters using? This will help us validate the feature once implemented.

This is aligned with the MeshCore support roadmap. I'll hold on implementation until @Yeraze gives the go-ahead. The work spans ~5 files plus a new migration and is self-contained.

Generated by Claude Code

Uh oh!

[FEAT] 2 and 3 byte support #3670

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions