feat(cc-peer): reply path via lazy per-correspondent aliases - #182
Merged
Merged
Conversation
Reply aliases (agent-comms#158) need cc-peer's AliasPool, published under the cc-peer/alias-pool subpath in 1.4.1 (agent-comms#40).
Derives a deterministic cc-peer peer name from a mesh correspondent's device-id and tracks the correspondent-to-alias mapping in a bounded, in-memory directory, bijective in both directions. Also identifies which DeliveryEvent types carry a single originating correspondent worth aliasing (dm, room_message) versus ones that describe something happening rather than a message from someone (room membership/status/ capability events). The directory is deliberately unpersisted: reply aliases are ephemeral by design, lost on restart and re-materialised by the next inbound message from that correspondent.
Adds CcPeerFront.handleAliasMessage, matching an inbound reply-alias message to the fronted session that sent it the same way handleInboundMessage already does, then resolving the alias to its correspondent via an injected directory. A resolved correspondent routes to the session's own handleAliasReply; an alias the directory no longer knows about (ephemeral aliases don't survive a front restart) routes to notifyStaleAlias instead of being silently dropped. A message matching no fronted session is dropped, same as handleInboundMessage, since there is nowhere to safely deliver an error for a session this front does not control.
Extends buildFrontedSessionRecord so a mesh delivery with a single originating correspondent (a dm or room_message) materialises that correspondent's reply alias before delivery and mentions it in the message body, so the fronted session can address a reply to that specific correspondent the way it addresses any other local peer. An event with no single correspondent (room membership/status/ capability events) still delivers via the shared peer unchanged; a failure to materialise the alias still delivers the message, just without a reply hint the session couldn't have used anyway. Adds handleAliasReply (translates a reply arriving on an alias into a mesh DM to that correspondent, sent as the session's own agentId) and notifyStaleAlias (a clear error back into the session for a reply on an alias the directory no longer recognises) to the record CcPeerFront tracks each fronted session under.
Wires cc-peer 1.4.1's AliasPool (cc-peer/alias-pool) and a shared ReplyAliasDirectory into the real cc-peer front construction: the pool is materialised lazily on first use, mirroring the shared CcPeer peer's own lazy-construction convention, and its "message" event (a reply arriving on any fronted session's own correspondent alias) routes straight into CcPeerFront.handleAliasMessage. Both the pool and the directory are shared across every fronted session on this machine, so two sessions corresponding with the same mesh agent share one alias rather than minting a duplicate. The pool is stopped alongside the shared peer when the front itself stops.
Extends the existing "Default cc-peer front" section with the reply path: lazy per-correspondent aliases via cc-peer's AliasPool, created only on inbound contact, ephemeral across restarts, and a clear error for a reply landing on a stale alias.
Mearman
marked this pull request as ready for review
September 17, 2026 17:49
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
🎉 This PR is included in version 3.12.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #158
Builds the reply half of the default cc-peer front (#157): a relayed Claude Code session can answer mesh agents natively, not just receive from them.
Design (as scoped in the issue): when a mesh agent messages a relayed session, the front materialises a cc-peer reply alias for that correspondent via cc-peer 1.4.1's
AliasPool(cc-peer/alias-pool), so the session can address a reply to that correspondent the way it addresses any other local peer. A reply arriving on an alias is translated into a mesh DM sent as the session's own device-id. Aliases are created only on inbound contact, are ephemeral (in-memory only, re-materialised by the next inbound message after a restart), and a reply to a stale alias produces an explicit error back into the session rather than a silent drop.Work in progress, following strict TDD one module at a time. Will flip to ready once complete and green.