I'm on the Chrome Remote Desktop team at Google, and I am working to add support for Wayland-based desktop environments. While our initial focus will be on getting it to work with GNOME, we'd love the functionally to be based on standardized APIs that can be used across desktop environments, so I'm reaching out here to see what interest there might be on the KDE side.
There's been a bit of discussion[1] on the GNOME Discourse, but to summarize, while the existing Portal APIs are great for remote assistance use cases where there is a local user to approve the session and mirroring the local display(s) makes sense, they are lacking functionality needed for the persistent remote access use case, where: * Connection should be possible immediately after boot. * For security, the session should operate in a headless mode while a remote connection is active and the physical seat should remain locked. * Virtual monitor layout should be configurable by the remote desktop tool to match the client, rather than mirroring the physical layout of the host. GNOME is currently pursuing an approach where the remote access tool runs as a system service, and connecting presents a login screen where the user can select a session and log in. Some handoff mechanism is then used for a process running in the resulting session to take over the connection. The current GNOME implementation is based on unstable, GNOME-specific APIs. As far as I understand it, there are three main pieces that would need to be standardized for this approach to work in a desktop-agnostic fashion: * An expanded remote desktop API for the compositor. Unlike the Portals API, this API would only be exposed to trusted processes and would not require a prompt for each session. Additionally, it would provide support for configuring virtual monitor resolutions, layout, and DPI, as well as support for accessing the clipboard. Jonas Ã…dahl has been working on creating a standard spec for this functionality, a draft of which is available at [2]. * An API for requesting a new remote display from the greeter, which the remote desktop tool could then attach to using the above API to allow the user to log in. This would also provide a method for the remote access tool to identify the resulting session. * A protocol by which the greeter can instruct the desktop environment to launch in headless mode for remote access, or (eventually) transition into/out of headless mode so the user can attach to the same session locally or remotely. Desktop Environments would presumably signal their support for headless / hybrid sesssions via an entry in their respective .desktop file. Of course, there are other approaches one could take, such as expecting the remote desktop tool to handle PAM authentication and session creation directly, rather than relying on the system greeter, or allowing individual users to set up a remote desktop tool as a user service that can only launch sessions on behalf of that user (which would require linger and wouldn't work with encrypted home directories, but would be more similar to how Chrome Remote Desktop currently works). Is such persistent remote access functionality something KDE would be interested in having? Do folks have thoughts on what they'd like to see such APIs look like? Thanks! [1]: https://discourse.gnome.org/t/persistent-remote-desktop-access-api/19415 [2]: https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1