Direct WebRTC connections in the desktop client
PqP’s Electron client can now establish a WebRTC path through the shared package, extending the transport work already integrated in the browser extension.
Bring the direct path to Electron
The Electron client now establishes WebRTC connections through the PqP package. The integration follows the extension’s shared-package transport work and brings the direct connection path into a second runtime.
A common package is useful only when the clients can actually drive it. This change connects the desktop message flow and WebRTC controller so the same core can participate in connection setup outside the browser extension.
Queues and direct connections have different jobs
Queue-assisted communication gives peers a mediated contact path. WebRTC provides a direct transport when the peers can establish a connection. A client needs to coordinate signaling and route messages to the component that owns that connection.
In Electron, that routing crosses application process boundaries. The integration aligns message handling with the transport controller instead of treating the desktop UI as if it had the same messaging environment as a browser background process.
A working path to investigate
This milestone gives the desktop implementation a direct connection path using the shared library. The useful next cases are lifecycle cases: restart a client, lose the connection during an exchange, or attempt to reconnect after the remote peer has changed state.
Connection establishment is one part of communication. A message still needs a clear outcome when a path fails or the recipient disappears. We can now study those behaviors across the browser and desktop clients without maintaining two independent transport implementations.