Skip to content

Gateway forwarding: advertise local agents, merge remote directory, route DMs with attribution #155

Description

@Mearman

The core leg of the cross-machine mesh epic: the gateway actually forwarding between the local mesh and the hub, in both directions.

Outbound advertisement: the gateway gossips local agents' peer-adverts over its hub connection, keyed by device-id, so the hub registers those devices as reachable via the gateway's connection and remote peers can establish relay pairings targeting them. Only visible agents are advertised; ghost is never advertised and hidden IDs are not propagated.

Remote directory merge: what the gateway learns from the hub's gossip and catch-up (already surfaced by HubSession.peers()) is merged into the local mesh's agent directory, so remote agents appear in local list_agents and can be addressed by device-id like any local peer.

Routing with attribution:

  • Local to remote: a send or DM whose target device-id is not a local peer routes to the machine's gateway, which rides its hub pairing (HubSession.sendToPeer shape).
  • Remote to local: inbound relay-data addressed to a local device arrives on the gateway's connection and is delivered over the local mesh to that device, attributed to the true sender. hub-session.ts already keys inbound requests by request.fromDevice rather than the hub; the same discipline extends to this path.

Two machines running this give the headline outcome: every agent on each machine sees the other machine's agents and can DM them, with no agent holding its own hub connection.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions