feat(core): route hub-relayed requests to the correct local peer via toDevice - #185
Merged
Merged
Conversation
wire-mesh#170 fixed the session layer's relay-pairing tracking and added IncomingManageRequest.toDevice, read from each relay-data frame's own field; wire-mesh#175 (following, once implementation here surfaced the gap) made relay-hub actually forward that field onward to the receiving peer, which toDevice disambiguation depends on entirely.
…toDevice Every inbound hub-relayed manage-request used to dispatch unconditionally against the gateway's own local state, even when it named a different device (toDevice) that this gateway also fronts as an ordinary local peer -- the known limitation hub-session.ts's own consume() doc comment flagged. It now forwards such a request on to that peer's own local mesh session (WireMeshTransport.sendToLocalPeer, extracted to hub-forwarding.ts) instead, falling back to the existing gateway-local dispatch when toDevice is absent or names the gateway itself, so a sender still on an older wire-mesh-core (never stamping toDevice) keeps working exactly as before. The forwarded command carries the request's already-verified true sender in a new "on-behalf-of" params field, and room-router.ts's own resolveHandle substitutes it for the request's dispatch identity once it reaches the local peer, so a capability token or a DM's own participant check still authenticates against the real remote origin rather than this gateway. resolveHandle only honours that field when the session's peer identity matches this side's own recorded coordinator device (WireMeshTransport.coordinatorDeviceHex) -- checked by identity rather than by which call established the session, since mesh formation's own reciprocal connectToPeer can reach a coordinator over a second, independently-accepted connection to that identical device. Also extracts readvertiseGossip into gossip-directory.ts, under this repo's max-lines cap once the above pushed wire-mesh-transport.ts over it.
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.14.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 #184
Summary
Bumps
wire-mesh-coreto 1.48.2, which carries both wire-mesh#170 (IncomingManageRequest.toDevice) and wire-mesh#175 (ExaDev/wire-mesh#175,relay-hubactually forwardingto-deviceonward to the receiving peer, a gap found while implementing this issue -- see that PR for detail).In
hub-session.ts'sconsume(): when an inbound hub-relayed request carries atoDevicenaming a different device than this gateway's own, it's now forwarded on to that device's own local mesh session (sendToLocalPeer, extracted tohub-forwarding.ts) instead of being dispatched unconditionally against the gateway's own state. Falls back to the existing behaviour whentoDeviceis absent or names the gateway itself, so a sender on an olderwire-mesh-corekeeps working.The forwarded command carries the request's already-verified true sender in a new
"on-behalf-of"params field (the same open-params-tail conventionroom.send's"streaming-behavior"already uses).room-router.ts'sresolveHandlereads it back out on the receiving side and substitutes it for the request's dispatch identity, so a DM's own participant check or a capability token's bearer check still authenticates against the real remote origin rather than the gateway -- without this, the forwarded request would be attributed to the gateway itself, breaking every subsequent operation (a DMacceptRoomJoinkeyed by the wrong requester, aroom.sendtoken bearer mismatch). Only honoured when the session's peer identity matches this side's own recorded coordinator device (WireMeshTransport.coordinatorDeviceHex), checked by identity rather than by which call established the session, since mesh formation's own reciprocalconnectToPeercan reach a coordinator over a second, independently-accepted connection to that same device.Also extracts
readvertiseGossipintogossip-directory.ts, under this repo's max-lines cap once the above pushedwire-mesh-transport.tsover it.Test plan
hub-todevice-routing.integration.test.ts): a three-party scenario (gateway a1, non-gateway local peer a2, remote hub peer b1) proves a DM addressed to a2 lands in a2's own state (not a1's), with the true sender (b1) preserved through the forward, end to end including delivered message content.pnpm exec vitest run-- 1037 passingpnpm exec tsc --noEmit-- cleanpnpm exec eslint .-- clean (3 pre-existing, unrelated warnings)