Implement encryption for the Matrix integration

[besendorf]

The current matrix implementation sends unencrypted messages to the matrix room. It also does this in encrypted rooms. This might be a privacy or security issue depending on what messages are sent with the tests. It would be nice if the matrix integration would support e2ee. Here is the matrix documentation on what is needed for encryption:
https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide

[cuu508]

Encryption would be neat to have. What would implementing it entail for a Python web app like Healthchecks? Would we need a new python library as a dependency (what are the options?), would we need to run a background daemon process like with Signal, something else?

[cuu508]

Looked into this a little bit more.

Healthchecks currently talks to the Matrix Client-Server API directly. The communication is over HTTPS, but the server sees plain-text messages, so the communication is indeed not E2E encrypted. For E2EE the client would need to encrypt/decrypt messages client-side, store encryption keys client-side, store session state etc. This is out of scope for Healthchecks, and would need to be handled by a separate tool or library.

Looking at the available clients and libraries, there is the matrix-nio python library. Sadly no documentation aside from a few code examples and API reference. Looking at the docs and examples, it looks like one would need a good understanding of the Matrix protocol to use the library properly.

There is a CLI client, matrix-commander, built on top of matrix-nio. It has the high-level interface I'm looking for, for example you can send an encrypted message to a room with simple command:

matrix-commander -m "hello world" --room '#my-test-room:matrix.org'

Calls to matrix-commander are "heavy": it needs to start up, initialize communications to a server, send a single message, then clean up. running multiple instances of matrix-commander concurrently is not safe.

The integration with Signal is in many ways similar: the client must handle encryption, the server is a relay of encrypted messages. One-off calls to signal-cli are slow and heavy. Multiple signal-cli processes cannot use the same data directory. The solution is to run signal-cli as a daemon process, and talk to it via its API.

From my brief look, it didn't look like matrix-commander supports a daemon mode.