"Google Play Services lets Google do silent background updates on apps on your phone and give them any permission they want. Having Google Play Services on your phone means your phone is not secure."
Yes, Google can install a backdoored version of Signal. This is bad. But if you can't take that risk, you can install e.g. LineageOS without Google Apps, download the source code, reproducibly compile the apk, and install it on your android. If you have a better idea, maybe it can be implemented.
"A checksum isn’t a signature, by the way - if your government- or workplace- or abusive-spouse-installed certificate authority gets in the way they can replace the APK and its checksum with whatever they want."
If they can add a certificate on your smartphone/PC, why can't they replace Signal with malicious one? Why can't they replace F-Droid? There is no 100% method to solve this issue, unless perhaps if you can meet with F-Droid developers, obtain the authentic public key from them to verify the F-Droid client's signature. Calling SHA256 cryptographic hash a checksum shows slight dishonesty on your side. The differences in connotations between the words are significant.
F-Droid doesn't magically solve this problem. The root of trust comes from another SHA256 hash -- 61:DB:51:32:39:47:61:C4:D4:3F:8A:9B:AE:72:B0:2E:B0:8D:F3:B5:ED:F2:92:1C:7B:14:7E:2F:29:30:83:03 -- that authenticates the certificate of f-droid.org.
Or it comes from the hash F3:33:D2:E7:FA:A3:68:7F:B2:99:3E:6D:F6:9D:EE:1D:DA:77:36:11:DD:CA:B3:3A:B6:79:87:AA:40:56:94:22 that authenticates the MIT's PGP key server that has the signature verification key for F-droid clients: https://pgp.mit.edu/pks/lookup?search=f-droid&op=index All your suggestion does is, it adds a layer or two where we hope the NSA doesn't compromise them in case you'd want to use that chain to install and validate Signal. And even if you personally verify the authenticity of public key, you haven't solved the issue of private key exfiltration via hacking. You need expensive HW like HSMs to even start combatting exfiltration. And Google can afford those.
"...centralized servers and trademarks."
Of course you can't call a fork with the same or similar name as the original. You don't want malicious entities to create projects with names like "Signal Official Client" etc. Having distinct name helps both the fork and the original one.
Centralized servers fix a crucial issue, shitty designs that linger forever. It also fixes the issue of having to deal with backwards compatibility indefinitely. Moxie can actually see what versions are still deployed, and push updates to most users. The idea here being, you don't have to support older protocols (e.g. the group chat had a big issue that was or is currently being worked on), implement backwards compatilibity that risks downgrade attacks etc.
Let me give you an example. Riot decided to go with stupid, stupid base64 public key fingerprints. What happens here the only way to jump to smart choice of base10, is if all clients switch at the same time. If one client shows fingerprint in different base, it's not compatible. Sure, you can add a feature that lets the clients negotiate which fingerprint to use but then you need to get that deployed to every client. This happens really slowly, and it must usually follow the waterfall model with first deciding about these things on future revisions of Matrix protocol. And if you want to know how that will turn out, take a good look at OpenPGP research group: since SHAppening, they haven't even been able to agree on a new hash function for fingerprints. And once decided, that hash function will wait for years before the next revision of protocol is ready. Then you wait for it to be implemented in upcoming reference libraries and forks of those. And then you wait for them to be deployed in clients. Moxie changed all users' fingerprints from Base16 to Base10 -- my guess -- within a week by pushing the update. The advantage of agility is obvious.
"But we have to trust that Moxie is running the server software he says he is."
For content encryption, we absolutely don't have to trust him. For metadata, yes, we must trust the server runs the version that only collects registration date and some other minor detail, I forget. If you want to remove metadata, use Ricochet or Briar. Because Signal isn't lying about being anonymous by design, the only thing I think we can agree is, it should be stated in clear on their front page: "End-to-end encrypted, but not anonymous, we know your phone number and IP-address, and can see who you talk to, when and how much".
"We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats."
Yes, but that doesn't prevent global passive adversaries from seeing who we connect to directly. In some authoritarian country, the government could see Alice and Bob talk to each other. With centralized design, they only see connection to service providing domain fronting, or connection to Signal server at most. If you really wanted to solve this, you would run Ricochet or Briar.
Federation is a horrible idea. I trust they are not interested in my metadata personally. I won't trust metadata of all my chats to a friend of mine who runs personal instance of Signal Server. He watches porn on that same computer. He downloads Russian game cracks to that computer. He has friends who are my enemies and vice versa. He has repressed personal grudges, reasons to fuck me over, or he doesn't have 50M in foundation money (and he'd prefer $5k over our weekend hang-outs that admittedly are getting boring) or strong cypherpunk ideology to prevent corruption. He's a chinese refugee who has relatives he loves in political prisons, waiting to hand out their organs to rich members of the political party, and he's being extorted for my metadata on his computer. His computer isn't patching itself automatically so there as RCE vulnerability that got him compromised by our common adversary. He clicked on wrong link, once. The number of threats is endless.
Federated system doesn't distribute risks across hundreds of operators, it increases the attack surface tremendously, while dropping the number of targets the metadata of which is compromised at the moment. But I don't care about others, I care about the fact my friend doesn't have as good security as Google and Signal devs. Government agencies are really, really, really, really good at hacking and the trend is towards mass hacking. Having shitty servers makes that free because you can use exploits that should already be useless due to system updates.
"Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network -"
Yeah let's talk about that. Currently many Matrix channels lack end-to-end encryption because there is a backdoor: an IRC-bridge bot that leaks all conversations to non-end-to-end encrypted environment. Like you said: "Tradeoffs are necessary - but self-serving tradeoffs are not.", the possibility of having bots is extremely dangerous. The fact Matrix isn't end-to-end encrypted by default is horrible. The E2EE is in beta, and the fingerprint verification in clients suck. For the past three years I've been complaining about this, every time there is a developer assuring this will be fixed. This bug should never have existed in the first place. Now the users have come to accustomed to having the possiblity for briges to insecure systems.
"but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests."
You should not make such generalized defamatory claims if you want to be taken seriously. I took this seriously at start but your arguments really lost their traction. It was another badly thought post that didn't show understanding of design choices and that hurt more than in helped: People might now switch to less secure Matrix protocol. Or they might even go with unaudited Tox, designed by non-experts.