I expect more of people on this forum honestly.
Taking the core of your argument: "Trust".
The point of E2EE is that we don't trust the network. We put all the trust in the client, something we control. Or at the very least we seperate our concerns. (please refer to this lovely interactive "Tor" diagram by the EFF for what I mean by splitting out concerns: https://www.eff.org/pages/tor-and-https )
Not being able to run your own client is a pretty big problem. At the very least in that case you should expect to be able to run on another network.. Otherwise that's a lot of trust for one entity and it's not different than just using TLS with HPKP/CA pinning
To give a direct refutation to one of your points: "Isn't WebRTC open source too?"
It is, but they're using native libraries which are compiled. Like I said, it's a good argument, but the result is that they don't have reproducible builds.
> Their code, their decisions.
Extremely dismissive, almost to the point of insulting.
It is absolutely not true that they are above criticism because they built something. They've positioned their product as a security product. Thus it will be judged on those merits. There are many pro-signal zealots who will bend over backwards to defend it in all circumstances. It's intellectually dishonest to do so in the face of valid criticisms.
I will shut up when federation is supported, or you can run your own network, or you can bring third party clients.
You need this to be able to trust your client, because the point is to decouple some trust from a single entity.
that's what e2ee is!
