While I'm very excited about the prospects for Matrix in 2019, the reality of client choice for end-to-end encrypted Matrix chat is currently disappointing compared to the potential it has. Someone on reddit gathered some data [1] about E2EE support a few months ago, and Debian maintain a wiki page [2] about their progress packaging Matrix-implementing applications. [1] https://www.reddit.com/r/privacy/comments/9avye…
I bear no ill-will towards the Matrix project, but this fact pattern (I knew about it in the abstract but hadn't seen it laid out like this) makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire. Telling people to switch to Matrix from those is simply malpractice.
Matrix at FOSDEM 2019
91–97 of 97 posts
Re: Matrix at FOSDEM 2019
#92Earlier quoted context omitted.
> Going back to tapping out messages on my phone in iMessage ...turns you back into a first class iMessage citizen. Meaning better security, more features, and a special color for the messages to signal all that to your recipients with an iphone.
> Meaning better security, more features If I'm understanding you correctly, are you suggesting that iMessages has a superior security protocol than Matrix?
* OP has an iphone and some kind of non-iphone messaging interface accessed through ssh which can somehow send messages to iphone users through iMessage
* OP prefers to use the non-iphone messaging interface to send messages to iMessage recipients (I'm assuming both OP and recipients are using a modern generation of the iphone)
I'm saying that-- as it stands today-- OP is accepting a decrease in security by sending to the iMessage recipients from the non-iphone setup instead of from OP's iphone.
Regardless of the security protocol of Matrix and regardless of which client OP is using, what I'm claiming will be true.
It's also trivial to refute-- if I'm wrong then the messages OP is sending from their custom box should show up with a blue background in iMessage on the recipient's iphone. Is that the case or not?
Re: Matrix at FOSDEM 2019
#93Earlier quoted context omitted.
I bear no ill-will towards the Matrix project, but this fact pattern (I knew about it in the abstract but hadn't seen it laid out like this) makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire. Telling people to switch to Matrix from those is simply malpractice.
Signal is a proprietary service. As it is security-oriented, for me it looks like a clear honeypot, so I would never use it. Matrix is much better approach. While I don't like that they use flashy languages for their leading implementations instead of platform-native C/C#/Objective C/Java, it doesn't matter in the long run, what matter is standards and implementations will come.
Re: Matrix at FOSDEM 2019
#94Earlier quoted context omitted.
The other comments already gave you some great info, but I'll just link some good documentation for anyone looking to get started. I discovered Matrix the other day and decided to set up a toy matrix-synapse server, which took less than two days' worth of free time for someone with a programming background and no serious IT expertise. Build matrix-synapse server from source: https://github.com/matrix-org/synapse Inst…
> Build matrix-synapse server from source: https://github.com/matrix-org/synapse Or use a distro that has a binary package, e.g. https://www.archlinux.org/packages/community/any/matrix-syna...
Re: Matrix at FOSDEM 2019
#95Earlier quoted context omitted.
> Now, there’s a long tail of other random clients which don’t do E2EE, which is inevitable given doing a good secure job of an independent E2EE implementation is obviously tough. But is that actually a problem, given the most usable mainstream clients do have it? Well, given that decentralisation is the primary differentiator from Signal (as far as I can see), everybody having to use the same client to get it is a b…
But they don't have to use the same client? The web, iOS/macOS & Android SDKs are completely independent, and have different clients written on them. Riot may be the main one, but Seaglass (on the macOS SDK) has full E2E support, and there are loads of projects building on the matrix-js-sdk which inherit its E2E support. Meanwhile the nheko project has an independent from-scratch implementation of the E2E stack, Frac…
True, but here is the repo:
"Note regarding End-to-End encryption - Currently the implementation is at best a proof of concept and it should only be used for testing purposes."
and:
"No longer maintained - Desktop client for the Matrix protocol"
Re: Matrix at FOSDEM 2019
#96Earlier quoted context omitted.
> Meaning better security, more features If I'm understanding you correctly, are you suggesting that iMessages has a superior security protocol than Matrix?
It has nothing to do with the protocol of Matrix. * OP has an iphone and some kind of non-iphone messaging interface accessed through ssh which can somehow send messages to iphone users through iMessage * OP prefers to use the non-iphone messaging interface to send messages to iMessage recipients (I'm assuming both OP and recipients are using a modern generation of the iphone) I'm saying that-- as it stands today --…
The distinction that the iOS messaging app uses to set the color of the message bubbles is whether messages are sent over SMS/MMS or iMessage. Since they're sent over iMessage, the message bubbles will be blue.
But yes, adding Matrix to the mix does add more potential failure points, since there are now two messaging protocols involved instead of one. That's just the nature of bridging messaging protocols though.
Re: Matrix at FOSDEM 2019
#97I found Matrix and Riot a while back while I was searching for an encrypted, open-source alternative to Rocket Chat for my team. While there are still some things that need improving, they're mostly just rough edges. All of my coworkers are at least semi-technical, so that makes things a little easier for us. At times, the key verification can be frustrating, but I think this is just a hard problem to solve in genera…
> This is the best and broadest attempt I've seen at this so far The old chaps around here had exactly the same hope for XMPP that you're having right now. It had it all, except, crucially, marketing.