> I beg to differ, it is very bandwidth heavy, around 4MBps by default. xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...
In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.
> xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)
While I am sort of amused to see my predictions from years ago coming true, it's still true that ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting, but it is important that you NOT DO THIS IT WILL NOT BE SECURE I PROMISE YOU WILL BE LYING TO YOUR USERS. I know SSH and TLS are both obnoxious to work with but EVERYTHING ELSE IS SNAKE OIL THERE IS NO-ONE ALIVE WHO IS SMART ENOUGH TO DO WHAT YOU ARE DOING SO STOP IT.
...goodness sakes, 2 minutes of googling suggests that TLS-SRP is even reasonably well supported these days. Use that. Please.