Signal is open-source in the "look at it, but don't even try to tun it" way. I'd rather support a protocol that supports federation and encourages alternative clients.

https://matrix.org is a good one

Not upvoting or downvoting, but Matrix is an experimental choice at this point. I have some hope for the near future, but so far Matrix protocol is far from an established standard.

> supports federation and encourages alternative clients

Currently, the only featureful matrix server (synapse) uses gigabytes of RAM just for a handful of users (see also progress on dendrite and conduit). As for supporting alternative clients, Matrix ecosystem has an overdependence on 3rd party web widgets (eg. Jitsi) for client features because they are not supported by the protocol itself yet, making it harder to implement a native client with good performance and all Element features.

As i'm writing this, i realize nheko client now supports WebRTC audio-video calls when a recent GStreamer is available, congratulations on that, and good luck for the multi-platform implementation!

> overdependence on 3rd party web widgets (eg. Jitsi)

Is there any other example than Jitsi? I thought that was the only third party integrated in the core, and even that can be self-hosted.

It may be the only one. I was simply aware of this example. My point is not that Jitsi cannot be selfhosted but that using it in your client means your client requires a full web rendering engine to provide that feature, making clients more resource-hungry. To be clear, i'm great it exists at all. It has provided useful services for tech conferences like FOSDEM. I'm just concerned with interoperability and the webification of everything.

Using HTTPS for transport as part of the matrix protocol is great for punching through firewalls, i'm just not convinced the rest of the web stack is well-suited to social networking usecases with a lot of information pouring in. Web engines and the DOM model were designed for static data, not for highly-dynamic information, although there's ongoing R&D around virtual DOMs to optimize those usecases.

Actually, Jitsi is the only one, but it used only in case of group calls, so I can't complain. 1:1 calls handled without any 3rdParty

You mean something like XMPP protocol, which is a widely-deployed IETF standard with robust free-software implementations?

Why doesn't Signal maintain an F-Droid compatible build? (if there's a dependency problem, then they should considering dropping it, release a Signal lite perhaps)

Making your own F-Droid repository was harder a few years back, and UX client-side was bad. Nowadays setting up a 3rd-party repo is as easy as scanning/approving a QRCode (for example for Newpipe repo).

Not that i approve Signal's attitude on this topic at all, but there are (were?) technical reasons for which they would do something else. Of course, F-Droid maintaining proper LibreSignal builds in their place alleviates the concern, and that's what Signal team famously opposed. For the uninformed, F-Droid has very serious review/build process for apps and i don't think malware was ever distributed on there (and antipatterns are listed in the UI client-side).

Probably the same reason they don't maintain a Flatpak, Snap, or any other package other than for Debian/Ubuntu for Signal-Desktop.

Which according to the GitHub discussion, the answer is: ????

> Signal team fought a long war against any forks or unauthorised builds of Signal.

Yeah, this is main reason why I avoid Signal together with Google Services usage.