Additions, features, clients for other platforms...etc

[yuroyami]

First thing that grabbed my attention upon using Syncplay (for the first time) is the lack of some really common languages (such as Hindi and Arabic).

I can localize Syncplay in Arabic if the GUI supports UTF-8 characters.

[Et0h]

We always welcome more translations and fortunately Syncplay supports UTF-8. The only thing which might not work is mpv support for recognising some non-Ascii characters for the chat input. See #500 for an example of the parts of Syncplay which need changing to add a language.

[yuroyami]

@Et0h Thing is, Arabic is RTL so I doubt it will go as I hope. I am giving it a try but somehow I can't get the app to build on Windows 7. Darn it.

[Et0h]

I expect that it would be possible to put Syncplay into RTL mode to accommodate an RTL translation using something like setAlignment(Qt.AlignRight | Qt.AlignAbsolute) on all the relevant widgets.

[yuroyami]

So Qt doesn't automatically detect (and therefore switch to) RTL languages such as Persian, Arabic etc ? I am kinda oblivious about how the GUI actually works. I would love to try translating the app first to see whether the texts are displayed properly without issues. I will get to it once I can as I barely have free time to even work on the Android client.

[yuroyami]

@Et0h Also, i have a few questions about the TLS connection. I am using a library called 'Netty' which is the Java equivalent of Twisted, however, certificates on Android are different from those of Desktop platforms (The format, for instance, is JKS). I can't say I have a full-fledged understanding of how certificates are fetched and approved (I am still digging into it), but I can't get the handshake to happen no matter what I try. Android has its own set of CAs already integrated in the system, but it's still boggling my mind. Syncplay uses Opportunistic TLS which I have already implemented (Meaning that, the server echoes back that TLS is supported, then and only then will the client try to establish an actual TLS connection. That, I know).

What I do know is, servers do not support self-signed certificates, does that apply to the server only or does it also apply to the client ? I have tried thoroughly reading the Python code that is triggered during the TLS connection establishing, but since I've never used Twisted before, it's hard to put my finger on the problem.

Does the client have to present a certificate (or a set of certificates) with a set of CAs that are only approved by the server ? Or Android's integrated CAs (which work fine for HTTPS for example, during browsing) should work just fine ? Am I misunderstanding this whole thing ? I believe the Android client can never be complete without the secure connection.

[Et0h]

I'm no SSL expert (hence why @albertosottile and @daniel-123 have taken the lead on TLS/SSL issues), but in my understanding:

• It is the server which has to have a certificate to support TLS, not the client. What the clients need is a way to determine whether or not to trust that certificate it receives from the server.
• The official Syncplay client uses Certifi to verify the authenticity of the certificate based on "Mozilla's carefully curated collection of Root Certificates for validating the trustworthiness of SSL certificates" (there's a Windows 11 bug on this which is being fixed as per Can't connect to official servers #554).
• Guidance on how to establish a valid certificate which would be accepted by our server and client software is set out at https://github.com/Syncplay/syncplay/wiki/TLS-support

Update: In terms of Let's Encrypt (which is what Syncplay uses and generally recommends for server certificate signing) information on Android compatibility can be found at https://letsencrypt.org/docs/certificate-compatibility/

[daniel-123]

Does the client have to present a certificate (or a set of certificates) with a set of CAs that are only approved by the server ? Or Android's integrated CAs (which work fine for HTTPS for example, during browsing) should work just fine ? Am I misunderstanding this whole thing ? I believe the Android client can never be complete without the secure connection.

Syncplay Server just expects self-consistent set of certificates that match the default practice like mentioned here. This is done because nowadays it's about as easy to get such set of globally valid certificates from Let's Encrypt as it is to generate a self-signed cert on ones own.

The client on the other hand takes the cert provided by server and "mindlessly" checks its validity against the list of trusted CAs. Said list of CAs is in perfect world just provided by python library which, again in perfect world, would either have it embedded or use CA list from OS. (yes, this is a bit of a rant towards #554)

In general I'd advise following the same path as we did - just pretend that self-signed certificates aren't a thing. Use cases for them are very niche, they are pretty annoying to deal with and if somebody really wants their own independent certificate they can spend 15 extra minutes and make their own private CA with entire chain signed by them anyway.

On Android I'd expect the certificates would be validated against its built-in CA list. This is not a problem for official servers as certificates we use are globally trusted.

One additional comment I'd make is that when selecting version of TLS, you can just go with 1.3. Syncplay in general is technically also compatible with 1.2, but that's only token level of compatibility and you don't need to care about it. We did have some internal discussions that we might remove support for TLS 1.2 in near future anyway.

[Et0h]

This discussion is being locked because as far as we can tell the discussion has run its course. If there are specific issues/ideas which arise out of it which you want to take forward then please create a dedicated discussion topic. Syncplay Android has been added to #570