Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is completely untrue and disingenuous; there are loads of Matrix implementations that support E2EE, and only one that happens to use Electron.

As of a few months ago, the list is: Element Web (via matrix-js-sdk), Element iOS (via matrix-ios-sdk), Element Android (via matrix-android-sdk2), the old Riot Android app (via matrix-android-sdk), weechat-matrix (via matrix-nio), weechat-matrix-rs (via matrix-rust-sdk), Mirage (via matrix-nio), Nheko (via mtx-client), gomuks (via mautrix), Seaglass (via matrix-ios-sdk), OCRCC Chatbox (via matrix-js-sdk), FluffyChat Flutter, Daydream via matrix-rust-sdk, etc.

There’s also pantalaimon (built on matrix-nio, and in future matrix-rust-sdk), which lets any Matrix client talk e2ee.

Hydrogen (github.com/vector-im/element-web) is also about to sprout e2ee via matrix-rust-sdk.



So Pantalaimon is something that needs to be added and configured, how easy is it to fuck up this configuration and accidentally send a non-E2EE message? Is it a program you can forget to launch? Is it something that can crash and make the user vulnerable?

How many of the apps you listed in second paragraph spawn E2EE chat by default?

How many of the apps warn about E2EE not being enabled when joining a room?

How many of the apps warn when E2EE is broken by e.g. IRC-bridge-bots?


Pan won’t let you send plaintext msgs in E2EE rooms. If you don’t launch it, your client can’t connect. It doesn’t have any known downgrade vulns. You can’t downgrade an E2E room to a non-encrypted one.

I haven’t checked to see which of those apps spawns E2EE chat by default. Element does, and I’d assume the other client devs are following suit; there’s no reason not to. Likewise, i haven’t surveyed to see what UI they use to warn for unencrypted rooms.

We’re currently working on an MSC to better advertise what bots/bridges exist in a room so you can track whether any is likely to be leaking your conversation to an unencrypted system. This is inevitably going to be on a best effort basis though.


> Element does

But does not warn regarding unverified seasons and will gladly send messages to them by default.


Apart from the official official clients:

weechat-matrix: https://github.com/poljar/weechat-matrix/issues/188 (doesn't support cross-signing)

weechat-matrix-rs: https://github.com/poljar/weechat-matrix-rs/tree/9c249f14038... (build failing, would be surprised if it supported cross-signing)

Mirage: https://github.com/mirukana/mirage/issues/32 (no support for cross-signing)

Nheko: https://github.com/Nheko-Reborn/nheko/issues/70 (automatically accepts keys as far as I understand)

gomuks: https://github.com/tulir/gomuks/pull/154 (seems to be the only mention of encryption, I don't see verification of keys or cross-signing)

Seaglass: https://github.com/neilalexander/seaglass/tree/dc97893343407... (seems to support e2e, but unfortunately macOS only)

OCRCC Chatbox: https://github.com/nomadic-labs/ocrcc-chatbox (404, couldn't find it)

FluffyChat Flutter: https://gitlab.com/ChristianPauly/fluffychat-flutter/-/tree/... (might support cross-signing, first client that I could actually use) Daydream: https://github.com/daydream-mx/Daydream/issues/11 (sounds to me like there's still some way to go)

Can you please not say that it's "completely untrue and disingenuous"? To me, working end-to-end encryption means that I can verify my own and other devices. Out of these, maybe Seaglass (macOS only) and FluffyChat Flutter support end-to-encryption in a way that I would use them. That's not "loads of Matrix implementations".

Can you recommend a non-official client with end-to-end support including cross-signing and device verification?


things building on matrix-rust-sdk will get cross-signing shortly too, fwiw. but it seems to be missing the point to pick the most recent e2ee feature (cross-signing) which landed a few months ago, and complain that not all clients have implemented it yet? this thread was originally about e2ee in general rather than a specific subfeature. e2ee is a constant work in progress: for instance, we’ve just added fallback otk keys and device dehydration - but that’s landing first in matrix-js-sdk (thus element-web) and then everyone else will implement as fast as they can. Sorry if that isn’t fast enough for your personal requirements :)


> disingenuous

I find this accusation quite offensive. I was under the impression that the standard here was to assume good faith. Please retract this statement.

> Element Web (via matrix-js-sdk), Element iOS (via matrix-ios-sdk), Element Android (via matrix-android-sdk2), the old Riot Android app (via matrix-android-sdk)

If anything counting all of these as separate implementations is the disingenuous thing here.

Admittedly though it seems that my knowledge on the topic was quite outdated. Glad to see that it improved in that front.


In addition such a statement goes against the Matrix code of conduct. https://matrix.org/legal/code-of-conduct

I would expect at least the project lead to follow it. Kinda sad to see the state of the Matrix community regarding hostility and hypocrisy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: