For a Linux user, you can already build such a system yourself quite trivially by installing an x11vnc server on your host, setting up a SSH tunnel to a remote server which forwards the host's VNC port, and sharing SSH credentials with your colleagues who can use a VNC client to access your screen from Linux, Windows or Mac.
that works quite well, especially between macOSes, but only down to 1Mbyte/s bandwidth, if u r sharing a FullHD.
below that bandwidth, the latency is getting into the annoyingly high territory.
and of course I'm taking about using it in approved quality mode.
it nicely handles HiDPI resolutions too, but unfortunately the built-in macOS vnc viewer can only scale down the screen, not up.
another issue is that zerotier doesn't work in China, but that's more of a social than technical issue unfortunately...
what I found is that Tuple.app makes a more useful compromise between latency and image quality. on low bandwidth your image might look like a balls of random pixels on first glance, but on a second look you can surprisingly still read it.
meanwhile latency remains below 0.5s, so you can keep thinking together with your pairing partner.
screen.so over low bandwidth keeps the image quality significantly higher than just-above-unreadable, but then you are experiencing jittery 1-6 second screen update frequency.
My team and I use Linux, so most of that doesn't affect me. Latency hasn't been an issue with VNC yet (we do fine with the lower qualities), but if it does, I have my eye on RDP and Jitsi Meet.
In addition to latency and legibility, I also value trust (so non-open-source clients are negatively treated), and CPU efficiency (WebRTC screen-sharing fails on this).
Thus, I cannot use Tuple.app (macOS only) and screen.so (which, on the surface, appears to be using Electron, and thus WebRTC).
