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.

> 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.