The bundled browser decoder reads the path-length byte as a plain byte count, so on a packet with 2- or 3-byte hops it misplaces everything after it. The modal took its header fields, path and payload from that decode first: a flood group-text packet (0x15) showed as 0x3D Custom, the path came out as dozens of single bytes, and the advert and decrypted sections read garbage. The header now comes from the byte on the wire, path and payload from the bot's own decode, and multibyte packets skip the browser decode with a note saying why. The tape skips browser decoding for them too ("multibyte path, not decoded here") rather than risk a garbled advert name or a false "no key here".
The rest is the polish pass:
- the modal shows the 16-character packet hash the tape, search and Copy hash use, not the decoder's 8-character one
- byte ranges account for transport codes ("Byte 4", not a fixed "Bytes 0-0"), paths are grouped by hop and payloads by byte so the hex wraps between bytes, and the path-length byte's bits are explained (hop count in bits 0-5, hash size in bits 6-7)
- colors come from the base.html theme tokens, light first with dark overrides, replacing a separate bluish dark palette and its light-mode patches; byte segments use the dashboard's categorical data colors as tints (5.3:1 and up in light, 8.9:1 in dark) instead of lamp green, amber and red, the hash is no longer amber and the binary column no longer red
- one level of cards: the raw bytes are a single well instead of a card holding a box with a 4px amber stripe, the segment cards carry a swatch that ties them to the bytes, and labels follow the viewer's small-caps style
- Copy raw hex is the primary button, and copying falls back to execCommand when the Clipboard API is missing (plain-HTTP LAN viewers), saying so if the browser still refuses
agessaman
84f06f8ebf