Found investigating wire-mesh#101 (web-console e2e room-messaging test). Two web-console instances connected to the same wire-mesh-node relay never see each other in their own Peer directory -- confirmed directly, both consoles' frame logs show their own self-advert gossip sent, zero frames received back.
Root cause in relay-hub.ts's handleFrame: the gossip branch only does devices.set(deviceKey(advert.device), {connection, device}) for its own relay-connect target lookup, then returns. It never re-sends or forwards the frame to any other connected client. There is no mechanism anywhere in relay-hub for a connected peer to learn about another connected peer's device-id via gossip.
wire-mesh-node's server.ts confirms this is the only path a hub connection ever goes through -- hub.handleConnection(connection), pure createRelayHub() logic, nothing else.
This means the checked-in webrtc.spec.ts e2e harness only works because it exchanges deviceA/deviceB directly between the two Playwright page contexts in the test process itself (window.harness.connect() returns the device-id as a JS value, passed straight into initiate()) -- not something a real end user could do through the UI. The actual web-console UI's directory (ConnectionPanel's Peer directory table, populated from event.directory) can currently never show a peer discovered through a shared hub, only a peer this session is directly connected to point-to-point.
Related but distinct from #102 (relay-hub dropping manage-request/response for capability-token enforcement) -- this is about gossip specifically, not manage-request forwarding. Needs its own design pass: relay-hub could re-broadcast a received gossip frame to every other currently-connected client, but that's a real behavior change (relay-hub is documented as "forwards blindly... never touches payload") worth thinking through rather than a one-line fix.
Found investigating wire-mesh#101 (web-console e2e room-messaging test). Two web-console instances connected to the same wire-mesh-node relay never see each other in their own Peer directory -- confirmed directly, both consoles' frame logs show their own self-advert gossip sent, zero frames received back.
Root cause in relay-hub.ts's handleFrame: the gossip branch only does
devices.set(deviceKey(advert.device), {connection, device})for its own relay-connect target lookup, then returns. It never re-sends or forwards the frame to any other connected client. There is no mechanism anywhere in relay-hub for a connected peer to learn about another connected peer's device-id via gossip.wire-mesh-node's server.ts confirms this is the only path a hub connection ever goes through --
hub.handleConnection(connection), pure createRelayHub() logic, nothing else.This means the checked-in webrtc.spec.ts e2e harness only works because it exchanges deviceA/deviceB directly between the two Playwright page contexts in the test process itself (window.harness.connect() returns the device-id as a JS value, passed straight into initiate()) -- not something a real end user could do through the UI. The actual web-console UI's directory (ConnectionPanel's Peer directory table, populated from event.directory) can currently never show a peer discovered through a shared hub, only a peer this session is directly connected to point-to-point.
Related but distinct from #102 (relay-hub dropping manage-request/response for capability-token enforcement) -- this is about gossip specifically, not manage-request forwarding. Needs its own design pass: relay-hub could re-broadcast a received gossip frame to every other currently-connected client, but that's a real behavior change (relay-hub is documented as "forwards blindly... never touches payload") worth thinking through rather than a one-line fix.