And FFS, it hasn't even got anything to do with protocol, it's something the client can do by itself. Having worked on secure messaging apps, I would never go to federated protocols. Signal's infrastructure allows rapid improvement of protocol and fast elimination of insecure protocol revisions. That's where we need to be at. Just look at the history of TLS and the potential in downgrade attacks. Old revisions die slowly. Signal can easily monitor what versions are still running, push updates to users and ensure codebase isn't bloated by code that merely represents insecure protocols.
Signal succeeds because of it's "closed" ecosystem, it doesn't suffer from the tyranny of the majority that occurs when there's disagreement about e.g. seriousness of some attack, when some feature might be risky. With Matrix, I worry developers of clients can affect choices, and the protocol is already dangerous, to ensure (backwards) compatibility with older clients and (other) protocols, Matrix is not end-to-end encrypted by default. I will eat my hat with mustard the day I see all Matrix clients support only end-to-end encryption for everything.
> Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.
> You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run. If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.
They've been able to iterate their protocol really fast thanks to it not being an RFC or something.