Matrix adapter: no E2EE support (olm/megolm) — encrypted rooms unreachable

[dancingclaw]

Description

The bundled Matrix adapter at crates/openfang-channels/src/matrix.rs is plaintext-only — it has no end-to-end encryption support. Most production Matrix deployments use encrypted rooms by default (Element creates DMs and most new rooms encrypted), so the adapter is effectively unusable in those rooms today.

Verified against v0.6.4 (3cce1eb):

$ wc -l crates/openfang-channels/src/matrix.rs
542 crates/openfang-channels/src/matrix.rs
$ grep -c -iE 'encrypted|olm|megolm' crates/openfang-channels/src/matrix.rs
0

Zero matches for encrypted, olm, or megolm — no olm/megolm session management, no m.room.encrypted decryption, no outbound encryption, no key recovery, no cross-signing.

Expected Behavior

When [channels.matrix] is configured against a bot account that lives in encrypted rooms:

1. Inbound m.room.encrypted events are decrypted using a persisted olm/megolm session store (typical pattern: SQLite store keyed by a stable device_id).
2. Outbound replies into encrypted rooms are encrypted with the room's megolm session.
3. A configurable cross-signing / recovery-key option exists so the device can verify itself across restarts and key rotations.
4. The session/crypto store survives daemon restarts.

For comparison: matrix-rust-sdk (LGPL/MIT in apps that depend on it via the standard Cargo path; the SDK itself is Apache-2.0) provides this out of the box via Client::builder().sqlite_store(..).build() with the e2e-encryption + sqlite features. The Hermes project's gateway/platforms/matrix.py uses the equivalent in mautrix-python (mautrix[encryption]) and serves as a reference for what the surface area looks like.

Steps to Reproduce

1. Create a Matrix bot account on any homeserver.
2. Invite the bot into a default-encrypted room (Element-created DM works).
3. Configure OpenFang v0.6.4 with [channels.matrix] pointing at that account.
4. From the room, send the bot a message.
5. Observe the bot either silently drops the event or logs an inability to decrypt; outbound responses are sent unencrypted (and rejected/undecryptable by encrypted-room participants).

OpenFang Version

0.6.4 (commit 3cce1eb3fb19ad590a0937e039a8bf8bc09aba13)

Operating System

macOS (Apple Silicon) and Linux x86_64 — the gap is substrate-independent (it is a missing implementation, not a build issue).

Logs / Screenshots

Indirect evidence — the source itself:

$ grep -c -iE 'encrypted|olm|megolm' crates/openfang-channels/src/matrix.rs
0

When deployed in an encrypted room, downstream symptoms are typically:

• m.room.encrypted events with empty body and algorithm: "m.megolm.v1.aes-sha2"
• Outbound messages visible only to non-encrypted observers / not decryptable by room members

Suggested Direction

Two reasonable paths:

1. Re-host the adapter on matrix-rust-sdk — the Rust-native SDK with first-class olm/megolm + SqliteCryptoStore + cross-signing. Pro: minimal surface to maintain, idiomatic Rust. Con: adds a fairly large dep tree.
2. Document the gap and recommend a host-side sidecar for E2EE-required deployments, with the bundled adapter explicitly marked plaintext-only in the docs.

Happy to test against a branch and provide a reference deployment if helpful.

[jaberjaber23]

Confirmed against current main. crates/openfang-channels/src/matrix.rs is a hand-rolled Client-Server API client over reqwest (542 lines, /sync long-poll, password + refresh-token flow, invite accept) with no crypto surface. Verified: zero references to olm, megolm, encrypted, or m.room.encrypted in the file. Your reproduction matches what's there.

Recommendation: rehost on matrix-rust-sdk, not vodozemac directly.

Two reasons:

1. vodozemac alone solves the wrong layer. vodozemac (Apache-2.0, maintained by the matrix.org foundation, the spiritual successor to libolm and what the official SDK uses internally) gives us olm 1:1 sessions and megolm group sessions as raw primitives. That's necessary but nowhere near sufficient. We'd still own: device key upload (/keys/upload), one-time key replenishment, device-list tracking with /keys/query + /sync device_lists deltas, to-device message handling for key requests/forwards, room-key sharing on membership changes, cross-signing identity (master/self-signing/user-signing keys), SSSS recovery, and a crypto store with proper concurrent-access guarantees. That's roughly the body of work matrix-sdk-crypto already encapsulates. Recreating it in-tree is a 6-12 month project that we'd then have to keep in sync with spec changes (MSCs around key backup, sliding sync interop with E2EE, etc.).

2. matrix-rust-sdk is the path of least surprise. Apache-2.0, used by Element X, actively maintained. The e2e-encryption + sqlite features give us SqliteCryptoStore out of the box, Client::builder().sqlite_store(path, passphrase).build() handles the encrypted store on disk, and Room::send() transparently encrypts in encrypted rooms. The hardest decision becomes how much of our existing /sync loop we throw away vs. keep.

Path forward:

• Add matrix-sdk = { version = "0.7", default-features = false, features = ["e2e-encryption", "sqlite", "rustls-tls"] } to openfang-channels. Pin a release, not git, so we control crypto-store schema migrations explicitly.
• Replace the manual reqwest client in matrix.rs with matrix_sdk::Client. Persistent state goes under ~/.openfang/state/matrix/{user_id}/ (store_passphrase derived from KernelConfig.secrets_key so the crypto store inherits whatever key management we already trust). The current Zeroizing<String> access-token handling moves into the SDK's session restore path via Client::restore_session().
• Cross-signing: expose a one-time openfang matrix verify CLI subcommand that prompts for the recovery key, calls client.encryption().recovery().recover(passphrase), and then bootstrap_cross_signing() if uninitialized. This is the operator UX inflection point — without it, every restart leaves the bot device unverified and other clients show the "unverified session" warning.
• Outbound: encrypted-room detection becomes implicit. Room::send() handles it.
• Inbound: the /sync handler decodes AnySyncTimelineEvent instead of raw JSON; Room::decrypt_event is what we'd call manually if we ever bypass the SDK's auto-decrypt path.
• Config: add [channels.matrix.encryption] with enabled: bool (default true), recovery_key: Option<Zeroizing<String>>, cross_sign_on_first_run: bool.

On Option 2 (document the gap, recommend a sidecar): acceptable as a v0.6.x stopgap, but it's a strategic dead-end. Matrix is moving toward encryption-by-default everywhere; Element-created DMs and most spaces are already encrypted. A "plaintext-only" adapter is a "doesn't actually work" adapter for the majority of real deployments. We should ship Option 1.

Blocker: matrix-sdk pulls in a non-trivial dep tree (around 200 transitive crates including vodozemac, ruma-*, matrix-sdk-base, matrix-sdk-crypto, an embedded sqlite if we don't share rusqlite). The real call is whether we feature-gate Matrix entirely behind --features matrix on the openfang-channels crate so non-Matrix users don't pay the compile-time cost, or just take the hit because Matrix is a first-class channel. I'd vote feature-gate; sets precedent for other heavy adapters (XMPP via tokio-xmpp is the obvious next one).

Happy to take a swing at the PR if scoping is agreed. The reference is right next door — Hermes' mautrix[encryption] pattern in gateway/platforms/matrix.py maps cleanly onto the matrix-sdk surface.

Spec refs: https://spec.matrix.org/v1.11/client-server-api/#end-to-end-encryption, https://matrix.org/docs/matrix-concepts/end-to-end-encryption/, SDK docs at https://docs.rs/matrix-sdk/latest/matrix_sdk/encryption/index.html.