[evanacci]

Cause

Under --pairing-policy ask, Stage A built pairing.request from the transport address and set remote_device_type to the literal unknown.

• The QUIC answerer passes a synthetic peer 0.0.0.0:0 into the framed session, so the Mac Studio Accept sheet showed 0.0.0.0:0 / unknown.
• The WS answerer passes the real TCP peer, so the connected session showed 192.168.4.25:55170.
• HELLO carried no device name. Signaling device names never reach this path (the MacBook offerer label was fixed separately in localbolt-native).

The native Accept sheet and the post-accept session label both read pairing.request remote_device_name.

Fix

HELLO inner JSON gains optional deviceName and deviceType. Both are omitted when this daemon has no usable name, so legacy HELLOs and existing vectors still parse. A bind address or ip:port is never sealed in and is never copied into IPC.

This daemon advertises --device-name, or the hostname with one trailing .local removed. --device-type defaults to desktop (phone, tablet, laptop, desktop, browser).

The answerer parses the peer HELLO before Stage A and puts that name and type on pairing.request. session.connected carries the same pair. When the peer sent nothing usable, both events use Unknown device / unknown.

How Mac Studio shows the MacBook

1. The MacBook daemon seals its name into the inbound HELLO (--device-name, otherwise the hostname).
2. The Studio daemon reads deviceName / deviceType from that HELLO before the ask prompt.
3. pairing.request carries those fields. The Accept sheet shows them, and the post-accept session copies the same name.

An older MacBook daemon that omits deviceName shows as Unknown device. The sheet does not fall back to 0.0.0.0:0 or 192.168.4.25:55170.

localbolt-native can later pass --device-name from the System Settings computer name. Until that flag is set, the advertised name is the unix hostname with .local removed.

Tests

• Address-shaped strings (0.0.0.0:0, 192.168.4.25:55170, bracketed IPs) are rejected as names.
• HELLO round-trips a human name and drops a socket-shaped claim.
• pairing.request from Stage A and from enforce_session_trust shows Evan's MacBook Pro / laptop when the peer address is 0.0.0.0:0.
• A socket-only peer becomes Unknown device.