Pre-flight checklist
Problem / motivation
Are there plans to implement a open source version of the "Flow" feature in OpenLogi so that one can move their mouse and keyboard to/from other systems in the way that the Logitech feature currently works? Really think this would be the nail in the coffin for Logitechs otherwise garbage software and would def. get me and many others to move off of it once OpenLogi is stable and has a stable working opensource version of "Flow".
https://support.logi.com/hc/en-us/articles/360023188134-Logitech-Flow
Proposed solution
Implement a similar open source feature in OpenLogi. Technical details on how Flow works are pretty straight forward. Here's a general description as a sketch out:
Network Communication
The technology uses UDP for low-latency transmission of cursor coordinates and clipboard data. Devices initially find each other via UDP broadcast or multicast on the local subnet. If they're on different subnets, the Logitech Presence Service (cloud) helps with the initial handshake by exchanging public IP information, but the actual data stream stays peer-to-peer or routed locally when possible. Once paired, all cursor movement, click events, and clipboard contents (text, images, files) are sent directly between the Logitech Options software instances on each computer.
Ports and Security
Logitech Flow dynamically assigns ephemeral high-numbered ports (typically 49152–65535) for its data streams. It doesn't rely on a single fixed port, so it can traverse NAT more easily once the connection is established. Firewalls must allow outbound and inbound UDP/TCP traffic for the Logitech Options application specifically. All data traversing the network is secured with AES-256-CBC encryption. The system uses Perfect Forward Secrecy (PFS), generating unique, ephemeral session keys for every connection. These keys are never stored on disk. Even if a session is intercepted or a device is compromised later, past data transfers can't be decrypted.
Alternatives considered
No response
Related area(s)
Additional context
No response
Pre-flight checklist
Problem / motivation
Are there plans to implement a open source version of the "Flow" feature in OpenLogi so that one can move their mouse and keyboard to/from other systems in the way that the Logitech feature currently works? Really think this would be the nail in the coffin for Logitechs otherwise garbage software and would def. get me and many others to move off of it once OpenLogi is stable and has a stable working opensource version of "Flow".
https://support.logi.com/hc/en-us/articles/360023188134-Logitech-Flow
Proposed solution
Implement a similar open source feature in OpenLogi. Technical details on how Flow works are pretty straight forward. Here's a general description as a sketch out:
Network Communication
The technology uses UDP for low-latency transmission of cursor coordinates and clipboard data. Devices initially find each other via UDP broadcast or multicast on the local subnet. If they're on different subnets, the Logitech Presence Service (cloud) helps with the initial handshake by exchanging public IP information, but the actual data stream stays peer-to-peer or routed locally when possible. Once paired, all cursor movement, click events, and clipboard contents (text, images, files) are sent directly between the Logitech Options software instances on each computer.
Ports and Security
Logitech Flow dynamically assigns ephemeral high-numbered ports (typically 49152–65535) for its data streams. It doesn't rely on a single fixed port, so it can traverse NAT more easily once the connection is established. Firewalls must allow outbound and inbound UDP/TCP traffic for the Logitech Options application specifically. All data traversing the network is secured with AES-256-CBC encryption. The system uses Perfect Forward Secrecy (PFS), generating unique, ephemeral session keys for every connection. These keys are never stored on disk. Even if a session is intercepted or a device is compromised later, past data transfers can't be decrypted.
Alternatives considered
No response
Related area(s)
Additional context
No response