What does HackerNews think of pantalaimon?

Well, if you want end-to-end encryption, then obviously that's going to be hard to write from scratch(!) - especially if you want it to be secure. However, we make it trivial to get up and running by piping your client through a proxy like Pantalaimon (https://github.com/matrix-org/pantalaimon/) which takes your normal traffic and makes it E2EE.

Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)

Same, it feels so sluggish and slow compared to xmpp clients, even in small private chats, public rooms on matrix are on another level of unusable. Also that element is the only client that supports all features, would love to switch something more lightweight but most of them have some features missing (that i would miss) or even e2ee missing.

Kind of funny that your name matches an e2ee matrix proxy. https://github.com/matrix-org/pantalaimon

I've tried to set up some Matrix projects. The Client-Server API is easy to work with, but as soon as encryption is involved, things start getting messy. Many libraries have a hard time working right with E2EE enabled, because suddenly you need to keep track of all manner of things that aren't always documented well.

I tried to hack E2EE in by using Pantalaimon [0] but running that on a server with the necessary management capabilities is very tricky and doesn't do cross signing, so I've come to the conclusion that it's effectively useless for my use cases.

Every now and then I check back on the current state of E2EE in libraries and it does seem to be improving. Hopefully the entire process becomes easier next time I get the time to work on my proof of concept code.

[0]: https://github.com/matrix-org/pantalaimon

matrix-nio's encryption is very robust now, but by far the easiest way to hook up a simple commandline script is to pipe it through pantalaimon (https://github.com/matrix-org/pantalaimon) - which acts as a daemon to offload E2EE from your script, using matrix-nio under the hood.

Luckily, the good folks at Matrix have thought of the client support issue: https://github.com/matrix-org/pantalaimon

So Matrix has a bunch of enterprise integration support either in existence or in the making.

In terms of audit compliance for E2EE, there are three main options:

a) Turn it off (as per the parent post); there isn't a button for this in synapse but would be possible to add, albeit technically an abuse vector given it is effectively a downgrade attack.

b) Add an audit user to rooms which need to be 'on the record'. This is our preferred solution, as it makes it crystal clear to users as to which conversations are on the record (and whose record!) and which aren't. One could run such a user via a client like https://github.com/matrix-org/pantalaimon, and have the server autoinvite them into rooms which need to be recorded.

c) Add an audit (aka ghost) device to users who need to be 'on the record'. For instance, you could use pantalaimon to log in as a given user and record their messages. The audit device will appear in the E2E devices for the user, and once cross-signing lands, could be signed by the user (or their sysadmin) to be trusted. However, we're not keen on ghost devices in general - we've built all of Matrix's E2EE trust model to protect users against unexpected devices being present in their rooms, so we'd recommend audit users instead.

In terms of LDAP integration - there are more and more enterprise integration options appearing; for instance, ma1sd is a maintained fork of mxisd, and we're working on better LDAP bridging for Matrix in general. We want Matrix to work in an enterprise environment, so if people see stuff missing, please yell.

> Can you find a concrete example of that?

I should have been more clear on that. Their own replies, look at their post history.

It's usually something like "Use Signal/Wire blah blah they are so good and will solve all the worlds problems". Someone then always points out that Signal requires you to share your phone number. Who wants to do that publicly?

Then people usually say the desktop client is pretty bad experience and you need Signal on your phone anyway to be able to use it. Even if you use a disposable SIM, the issue comes up with the number going back into the carrier distribution pool to be issued to new customers.

Phone numbers are a terrible way to identify people. Unlike email, where you can have spam filters, phone numbers have virtually no user controls for stopping unsolicited communications. Hell even IRC has that it's called /ignore.

Often then the next thing that gets mentioned is Signal does not like people making third party clients, so that means no nice TUI client or something that is native for your platform. I dunno about you, but I go out of my way to avoid Electron. I am thankful that at least with Matrix, there are other clients being developed, and tools like Pantalaimon that will allow for easy encryption everywhere. https://github.com/matrix-org/pantalaimon

I have blind friends and they say Electron applications are terrible. By that I mean non-functional with their screen readers, so that's a 0/10 for accessibility.

And then someone else always points out Wire has metadata and isn't even federated like Matrix so you're back to square one.

(Matrix project lead here.) The linked reddit post is 10 months old, and even then was riddled with bugs (it ignored or declared 'unclear' for some of clients which had E2E, and included loads of random alpha ones to make the situation seem way worse than it was). The topmost reply on that post tried to correct it at the time, but seems like people don't read the replies.

The current situation is that the following clients in Matrix have full E2E support:

* Riot/Web (JS) (aka Riot/Desktop)

* Riot/iOS (ObjC)

* Riot/Android (Java)

* RiotX/Android (Kotlin)

* Weechat (Python)

* Pantalaimon (Python)

* Seaglass (ObjC on macOS)

* Nheko (Qt) (other than file transfer)

Meanwhile, Quaternion (Qt) is currently getting support via GSoC 2019, and the purple-matrix plugin has working (albeit read-only) E2E support. I believe Pattle (pattle.im) is working on E2EE too. And the matrix-python-sdk (not an app) got support via GSoC 2018.

It's true that there are over 100 other Matrix clients out there which don't speak E2EE natively, but that's because "a matrix client" can be as simple as a curl one-liner, and so there are tonnes of experimental and toy and alpha ones as well as the more mature ones which you could use to pad out a list to make native E2EE support look bad.

However, and most importantly, Pantalaimon (https://github.com/matrix-org/pantalaimon) makes any Matrix client (including all the ones in that FUDdy Reddit post) speak full E2EE - by running as a clientside daemon which acts as a friendly MITM for your Matrix traffic and offloads all the hard E2E encryption (and E2E indexing and search, and in future multiplexing multiple local Matrix apps onto one connection to your server - thus acting almost as a general comms daemon which can even be used as a self-sovereign encrypted push service).

That said, I agree that sometimes the enthusiasm of the Matrix community can be overzealous. For instance, there are some bits which we haven't solved yet, for instance:

* Cross-signing keys for one-hop web-of-trust is 1-2 weeks away from landing. It's implemented in Synapse and matrix-js-sdk, but we're in the middle of adding it into the UI for Riot/Web currently. You can see demos at the SDK level at https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-... if interested. We also need to figure out how to use cross-signing for limited transitive web-of-trust (e.g. within an closed organisation where WOT metadata leakage isn't a concern)

* We don't turn on E2E by default yet for private chats. This is because we want cross-signing to land first, for usability, and also because we don't want to lock out non-E2E-capable clients, and pantalaimon is only a few weeks old. We also want to better solve e2e-search first (by taking the tantivy-powered FTS indexer from pantalaimon and putting it into Riot). Also, we are still chasing down a few edge cases where session keys aren't available - see https://www.youtube.com/watch?v=WgikPxIjsWE for our approach to that, and https://github.com/vector-im/riot-web/issues/6779 for the overall bug.

* We don't have any equivalent of key-servers at all yet.

So yeah, we definitely don't claim to be perfect, but please don't disregard our progress thanks to a confused/malicious Reddit article.

> Isn't this also the case with Matrix that no implementations except the official ones support E2E encryption?

A general purpose project to provide all clients with E2E encryption is being developed (and is usable right now): https://github.com/matrix-org/pantalaimon

Right now it runs as a daemon on a user's local machine.