The reply half of the cc-peer front: a relayed Claude session can answer mesh agents, not just receive from them.
Design: lazy per-correspondent aliases. When a mesh agent messages the relayed session, the front materialises a cc-peer peer name for that correspondent (alias to device-id mapping) so the session can reply natively, the way it replies to any local peer. A reply to an alias is translated by the front into a mesh DM, sent as the session's own device-id; that attribution only works because the front holds the session's slot identity (see the front issue). Aliases are created only on inbound contact, so they are bounded by real correspondents and never pollute the session's peer list with a directory; they are ephemeral, re-materialised by the next inbound message after a restart; and a reply to a stale alias produces a clear error back into the session rather than a silent drop.
Rejected alternatives, for the record: a single return-name with the target embedded in the message body (routing would depend on the LLM formatting a payload correctly); installing tooling into the session (that is just running agent-comms, which this front exists to avoid requiring); and materialising every mesh agent as a peer upfront (unbounded churn for no benefit).
Both directions are specified up front because two-way conversation is the point of the front; inbound lands first as build order, since the alias mechanism rides on it.
Open empirical gate: whether Claude Code's local peer protocol supports materialising peer names the session can reply to. Resolved by reading cc-peer's source before building; if the protocol cannot express aliases, this is redesigned against what it actually supports.
The reply half of the cc-peer front: a relayed Claude session can answer mesh agents, not just receive from them.
Design: lazy per-correspondent aliases. When a mesh agent messages the relayed session, the front materialises a cc-peer peer name for that correspondent (alias to device-id mapping) so the session can reply natively, the way it replies to any local peer. A reply to an alias is translated by the front into a mesh DM, sent as the session's own device-id; that attribution only works because the front holds the session's slot identity (see the front issue). Aliases are created only on inbound contact, so they are bounded by real correspondents and never pollute the session's peer list with a directory; they are ephemeral, re-materialised by the next inbound message after a restart; and a reply to a stale alias produces a clear error back into the session rather than a silent drop.
Rejected alternatives, for the record: a single return-name with the target embedded in the message body (routing would depend on the LLM formatting a payload correctly); installing tooling into the session (that is just running agent-comms, which this front exists to avoid requiring); and materialising every mesh agent as a peer upfront (unbounded churn for no benefit).
Both directions are specified up front because two-way conversation is the point of the front; inbound lands first as build order, since the alias mechanism rides on it.
Open empirical gate: whether Claude Code's local peer protocol supports materialising peer names the session can reply to. Resolved by reading cc-peer's source before building; if the protocol cannot express aliases, this is redesigned against what it actually supports.