PR #100 (closing #32) added the room-messaging UI (WebrtcNegotiator per relay session, useRoomMessaging, RoomPanel), unit-tested against fakes -- RoomPanel's own rendering/interaction is fully covered, but the negotiator's real WebRTC offer/answer/ICE exchange has no jsdom equivalent to test against (confirmed: webrtc-negotiation.ts's own existing test file covers only its pure helpers, leaving the live exchange to the checked-in Playwright harness at test/e2e/webrtc.spec.ts).
That harness already proves two real Chromium instances can negotiate a data channel through a real wire-mesh-node relay. It doesn't yet exercise anything above the raw data-channel level -- room.join, the join/approval decision, room.send, or a message actually rendering in the other side's RoomPanel.
Extending it to drive the full flow (two console tabs, each its own persisted identity, directory sees the other, click Message, approve the join request, send a message, confirm it renders on the other side with no manually copy-pasted token) is exactly the manual end-to-end check the original plan named as the real proof this design works -- automating it as a proper e2e test is the natural next step now that the UI exists to drive.
Investigated directly (writing the actual test): "directory sees the other" through a shared relay doesn't currently work at all. relay-hub only registers a gossip-advertised device internally for its own relay-connect target lookups -- it never forwards or re-broadcasts the gossip frame to any other connected client, so a console connected to wire-mesh-node never learns another connected console's device-id. The existing webrtc.spec.ts harness sidesteps this by exchanging device-ids directly between the two Playwright page contexts in the test process (window.harness.connect() returns the device-id as a JS value), which isn't something a real end user can do through the UI.
Filed as its own blocking issue: #110. A real e2e test for the full UI flow is written and ready (test/e2e/room-messaging.spec.ts) but currently skipped, referencing #110 -- unskip it once #110 lands, and it should pass unmodified against the real fix.
PR #100 (closing #32) added the room-messaging UI (WebrtcNegotiator per relay session, useRoomMessaging, RoomPanel), unit-tested against fakes -- RoomPanel's own rendering/interaction is fully covered, but the negotiator's real WebRTC offer/answer/ICE exchange has no jsdom equivalent to test against (confirmed: webrtc-negotiation.ts's own existing test file covers only its pure helpers, leaving the live exchange to the checked-in Playwright harness at test/e2e/webrtc.spec.ts).
That harness already proves two real Chromium instances can negotiate a data channel through a real wire-mesh-node relay. It doesn't yet exercise anything above the raw data-channel level -- room.join, the join/approval decision, room.send, or a message actually rendering in the other side's RoomPanel.
Extending it to drive the full flow (two console tabs, each its own persisted identity, directory sees the other, click Message, approve the join request, send a message, confirm it renders on the other side with no manually copy-pasted token) is exactly the manual end-to-end check the original plan named as the real proof this design works -- automating it as a proper e2e test is the natural next step now that the UI exists to drive.
Investigated directly (writing the actual test): "directory sees the other" through a shared relay doesn't currently work at all. relay-hub only registers a gossip-advertised device internally for its own relay-connect target lookups -- it never forwards or re-broadcasts the gossip frame to any other connected client, so a console connected to wire-mesh-node never learns another connected console's device-id. The existing webrtc.spec.ts harness sidesteps this by exchanging device-ids directly between the two Playwright page contexts in the test process (window.harness.connect() returns the device-id as a JS value), which isn't something a real end user can do through the UI.
Filed as its own blocking issue: #110. A real e2e test for the full UI flow is written and ready (test/e2e/room-messaging.spec.ts) but currently skipped, referencing #110 -- unskip it once #110 lands, and it should pass unmodified against the real fix.