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.
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!
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.