Vasyl Gello

@SyncedSynapse Install pvr.demo and you'll get everything needed to test. If you use Kodi on Debian, ping me and I will build you the debpackage. BTW time to try 3.0.0...

@heeplr What you refer is implemented in Yatse for a long time. Would be nice to have this functionality in Kore, too.

> Would we need to differentiate when authentication fails and when we just hit the next module in the server authentication list? I think we can follow OpenSSH workflow here...

> Which is? Server: Authentication methods supported: publickey, password, gssapi Client: Attempting to use password … Server: Authentication methods supported: publickey, gssapi `ssh -vvv`

Also, when we support more authenticatiin factors, I guess there will be no place for username/password in connect.html… Even now specifying password in connect.html does not prevent password pop-up from...

> No, I meant: how does it handle retries. From what I see in `ssh -vvv` output, the server first announces a list of authenticators (constraints) and when client sends...

So I dont understand how `sequential list of constraints` in Xpra server differs from sequential list of constraibts in industry-standard OpenSSH :)

> The packets don't have a source marker. This would need to be added to the xpra protocol. Why not use display number for it? Proxy can occupy :14500 or...

Tgen differentiation of servers is not needed. We can state in documentation that every server (be it proxy or backend) supports one authentication attempt of given type. Did I understand...

i think if we are going to add u2f etc, we need to differentiate the cases & clients. But I understand your concerns on breaking the backward compatibility