Comment by Arathorn
6 years ago
The slow bit of Matrix’s E2E by default isn’t the roll-out; we’ll also flip the switch when we get to that point. The problem instead was that we implemented way too many pre-E2E features (serverside search, etc) and have had to reimplement them to force everyone onto E2E.
So yeah, Signal’s approach to only roll out features if they’re privacy preserving is great. But it’s nothing to do with centralisation/decentralisation.
Do all the Matrix clients implement the E2E functionality that exists today, the functionality people talk about when they say Matrix is E2E encrypted? If not: that's decentralization in action.
Downthread, you were explaining that you're waiting to flip a switch to require E2E support for clients, and that there's a "pantalaimon" proxy service that people are going to have to use to retrofit E2E onto clients that don't support it. So I think I know the answer to this.
I'm always going to come across like I'm rooting against Matrix, which isn't what's happening.
It’s pretty simple.
There are a bunch of Matrix clients from various sources, with a wide spread of features and maturity. All the commonly used ones are pretty much feature complete and support E2E. The fact others exist is because they are WIP or experiments. This is a feature not a bug.
We’re declaring that private chats (or at least DMs) must default to being E2E at end of Jan. This could screw over these WIP and experimental or venerable clients, so we provided pantalaimon as a shim daemon to help them out.
To me, this says that we can successfully evolve Matrix with massive breaking changes by providing migration paths and decent layering abstractions, despite being decentralised.
So “Do all the Matrix clients implement the E2E functionality that exists today” is not a very revealing question.