rollback-pr review

documentation/routing-paths.md

@@ -18,18 +18,18 @@ The device capability determines the hash width (number of bytes per hop):
 
 ### Device Capability Detection
 
-On device connection, the app reads the firmware capability to set `pathHashByteWidth` reported by the device. The device encodes a "mode" value (0..3) which maps to `width = mode + 1` (1..4 bytes per hop). The connector uses this width as the authoritative send width when composing paths for that device.
+On device connection, the app reads the firmware capability to set `pathHashByteWidth`:
 
 ```dart
 // Read from device info response (offset 81)
 final modeRaw = firmwareBytes.length >= 82
-  ? (firmwareBytes[81] & 0xFF)
-  : 0;
-final mode = modeRaw.clamp(0, 3);
-_pathHashByteWidth = mode + 1; // 1..4 bytes per hop
+    ? (firmwareBytes[81] & 0xFF)
+    : 0;
+final mode = modeRaw.clamp(0, 2);
+_pathHashByteWidth = mode + 1; // 1, 2, or 3 bytes per hop
 ```
 
-Note: the app now supports up to 4 bytes per hop when reported by devices. UI validation for user-entered paths still uses the device's configured `pathHashByteWidth` for outbound paths, but inbound packets are interpreted per-packet (see below).
+The current implementation intentionally clamps to modes `0..2`, so the supported hop width is `1..3` bytes. Do not document 4-byte hops unless the connector implementation is widened first.
 
 ### Path Data Structure
 
@@ -56,24 +56,6 @@ Use this consistently when displaying hop counts in UI. Do not treat `pathLength
 
 - **Direct messages**: Extract path from decrypted payload to trace sender route.
 - **Channel messages**: Decrypt hop-by-hop routing chain from payload; the header carries the encoded byte length for the path blob, not the derived hop count.
-### Packet-aware parsing (incoming packets)
-
-Inbound frames may encode the effective hop width inside the path bytes themselves (top two bits of the first path byte). To avoid misinterpreting a 1-byte packet as a 2-byte path when the node configuration differs, the client detects the packet's width and uses it when splitting and matching hops for that specific packet.
-
-Use the per-packet detection for display, contact lookups and inferred-position calculations. Continue to use the device's configured `pathHashByteWidth` for composing and validating outbound paths.
-
-The helper used by the client implements detection equivalent to meshcore_py:
-
-```dart
-static int detectPathHashWidth(List<int> pathBytes, {int fallback = 1}) {
-  if (pathBytes.isEmpty) return fallback.clamp(1,4);
-  final first = pathBytes[0];
-  final mode = ((first & 0xC0) >> 6) & 0x03;
-  return (mode + 1).clamp(1,4);
-}
-```
-
-This ensures that display and matching are packet-aware and robust across mixed-width networks.
 - **Contact storage**: Path length in byte 32, raw path bytes in bytes 33-96, grouped by detected `pathHashByteWidth`.
 
 ### UI Hop Count Display